Should you use Strict or Relaxed alignment for your DMARC settings?
The DMARC standard enables a domain owner to allow relaxed alignment or to require strict alignment, do note however that there is no noticeable increase in protection by using Strict mode.
We do not recommend using Strict mode (unless you have a specific reason) since there is no improvement in protection but it does make configuration and management of authentication more difficult.
Relaxed alignment is achieved if the organizational domain is the same between the user-visible From address and either the Return Path (SPF) or authenticated with the DKIM signature.
Strict alignment on the other hand requires an EXACT match between the Fully Qualified Domain Name (FQDN) of the user-visible From address and either the Return Path (SPF) or authenticated signing domain (DKIM).
If strict alignment is required and the email does not pass strict alignment, the email is considered to have failed DMARC authentication for that method (SPF or DKIM).
Strict vs Relaxed alignment is specified in the DMARC record using the following tags:
aspf (SPF)
adkim (DKIM)
The default setting, if it is not specified in the DMARC record, is relaxed alignment. For example, the following DMARC records are equivalent:
If the user-visible From address is [email protected] and the authenticated signing domain is mydomain.com,
The email is not strictly aligned with DKIM
What is the return-path email header?
Return-path is a hidden email header that indicates where and how bounced emails will be processed. This header, also referred to as a bounce address or reverse path, is an SMTP address that is separate from your original sending address, and is used specifically for collecting and processing bounced messages.
Having a clear return-path system in place is incredibly important for your email program. It acts as a safeguard, protecting senders by providing a separate location for processing bounced emails. Your original sending inbox isn’t crowded by those “failed delivery” emails and that bounced messages are kept organized and together. Having a clear, organized return-path for bounced messages can also help your email deliverability and maintain your sending reputation.
To test whether your emails are compliant, try the Email investigation tool over at EasyDMARC.
Why is return-path important?
Return-path is an important tool to have at your disposal, especially for mass email sends. Let’s say you’re sending an email blast about an offer your company is promoting to your entire email list. While we don’t want to see bounced emails, the reality is that messages can and do bounce for a variety of reasons.
When you’re sending to large groups, you can get tens, maybe even hundreds of bounced messages depending on the size and nature of your campaign. These “failed delivery” messages then come back to haunt and crowd your original sending inbox. Instead, by having an established return-path, those messages are processed and stored separately in their own specified inbox.
Return-path also helps with your deliverability and sending reputation by helping to validate your identity as a sender (i.e. whether or not you’re sending spam). Because return-path is an SMTP address, it can be used by servers and inbox providers to decide how or if they want to filter your messages. Having a properly set-up return-path can help provide credibility for your messages and subsequently, you, the sender, which in turn boosts your sending reputation.
This can be a particular issue when using domain aliases (send mail as) with Google Workspace (gmail), as gmail will use the primary domain in the return-path and will thus fail authentication when using strict mode. To avoid this, use relaxed mode, which will fix spf alignment failed.
Below is an example where the primary domain is michaels.me.uk and the secondary (alias) domain is kopage.com, using send email as in the gmail settings.
The above report was generated using the email investigation tool at EasyDMARC.
How return-path works
Return-path specifies where bounced messages should go when they cannot be delivered. It is usually set up by your email or other relay platform provider but can often be customized.
Servers and inbox providers validate your identity and reputation before pushing your message through to recipients’ inboxes.
To get you through these filters, return-path and DMARC work together. DMARC examines your message to confirm that the domain provided in the “sent from” field matches the domain provided in the return-path field, which helps to validate your identity as a sender. After DMARC has verified and matched these domains, servers and inbox providers will be able to filter you out more easily.
Types of bounced emails
There are two types of bounced emails: hard bounces and soft bounces.
A hard bounce occurs when you have a permanent issue with a recipient, such as an invalid email address or typo in your mailing list.
Soft bounces are more temporary and usually occur when there’s a problem with a recipient’s inbox, including file size or attachment issues or the possibility of a recipient having a full inbox.
When a message hard bounces, the general best practice is to check that there are no typos in the recipient’s address. If there are none, you should remove the address from your mailing list. Keeping email addresses that hard bounce can damage your reputation as a sender and affect your deliverability in the long run.
When an email soft bounces, you have a little bit more wiggle room than with a hard bounce. Email addresses that soft bounce can be kept in your mailing list for future campaigns, but you’ll want to watch them to see if they bounce again. If they continue to bounce, they should be removed from your mailing list.
DKIM stands for DomainKeys Identified Mail and is used for the authentication of an email that’s being sent. Like SPF, DKIM is an open standard for email authentication that is used for DMARC alignment. A DKIM record exists in the DNS, but it is a bit more complicated than SPF. DKIM’s advantage is that it can survive forwarding, which makes it superior to SPF and a foundation for securing your email.
Starting in 2004 from merging two similar efforts, “enhanced DomainKeys” from Yahoo and “Identified Internet Mail” from Cisco and has since been widely adopted for email authentication.
What is a DKIM Record?
A domain owner adds a DKIM record, which is a modified TXT record, to the DNS records on the sending domain. This TXT record will contain a public key that’s used by receiving mail servers to verify a message’s signature. The key is often provided to you by the organization that is sending your email, for example SendGrid, Postmark, or Google Apps.
What is a DKIM Signature?
DKIM gives emails a signature header that is added to the email and secured with encryption. Each DKIM signature contains all the information needed for an email server to verify that the signature is real, and it is encrypted by a pair of DKIM keys. The originating email server has what is called the “private DKIM key,” which can be verified by the receiving mail server or ISP with the other half of the keypair, called the “public DKIM key.”
These signatures travel with the emails and are verified along the way by the email servers that move the emails toward their final destination.
How does DKIM work?
When an inbound mail server receives a message, it will detect the DKIM signature and look up the sender’s public DKIM key in DNS. The variable or DKIM selector provided in the DKIM signature is used to determine where to look for this key. If the key is found, it can be used to decrypt the DKIM signature. This is then compared to the values retrieved from the received mail. If they match, the DKIM is valid.
Read about DKIM Selectors and how to discover which ones your domain may be currently using.
Why use DKIM for Email?
Implementing DKIM for email provides major benefits:
Protection of message integrity. The content of the email can be verified that it hasn’t been changed while being sent.
Increases domain reputation and email deliverability.
One of the foundational methods of email authentication for DMARC.
How do I know if DKIM is working?
Test your domain’s DKIM settings – Our DKIM Inspector is a free diagnostic tool that check if the public part of your DKIM signature—using the selector—has been implemented correctly in the DNS of your domain. Our free DKIM Validator can help you verify that your DKIM record is properly formatted.
What happens when DKIM fails?
When DKIM alignment fails—or when the d= value in the Header From does not match the d= value in the DKIM signature—it can negatively impact deliverability as mailbox providers may send the message to the spam folder or block it entirely.
It is important to examine all messages that have failed to identify the sources as valid or as malicious. If you recognize a source as legitimate, you can investigate and set up DKIM correctly. If a source is not recognized, make sure to research it because this could indicate an attempt to send malicious emails on behalf of your domain.
Why DKIM-Only Isn’t Safe Enough
DKIM on its own isn’t a reliable way of authenticating the identity of the email sender and does nothing to prevent the spoofing of the domain visible in the header of the email. DMARC solves the problem by guaranteeing that the domain the end user sees is the same as the domain that is validated by DKIM and SPF. Learn more about DMARC alignment.
Furthermore, the addition of DMARC provides email received instructions on what to do with emails which do not match these checks via DMARC policy enforcement.
Domain-based Message Authentication Reporting and Conformance (DMARC) is a free and open technical specification that is used to authenticate an email by aligning SPF and DKIM mechanisms. By having DMARC in place, business owners large and small can fight the massive cybersecurity problems caused by phishing and reputation damage caused by spoofing.
With DMARC you can tell the world how to handle the unauthorized use of your email domains by instituting a policy in your DMARC record. The three DMARC policies are:
p=none
Monitors your email traffic. No further actions are taken.
p=quarantine
Sends unauthorized emails to the spam folder.
p=reject
The final policy and the ultimate goal of implementing DMARC. This policy ensures that unauthorized email doesn’t get delivered at all.
How does DMARC work?
DMARC is based upon the results of SPF and/or DKIM, so at least one of those has to be in place for the email domain. To deploy DMARC, you need to publish a DMARC record in the DNS.
A DMARC record is a text entry within the DNS record that tells the world your email domain’s policy after checking SPF and DKIM status. DMARC authenticates if either SPF, DKIM, or both pass. This is referred to as DMARC alignment or identifier alignment. Based on identifier alignment, it is possible that SPF and DKIM pass, but DMARC fails.
A DMARC record also tells email servers to send XML reports back to the reporting email address listed in the DMARC record. These reports provide insight on how your email is moving through the ecosystem and allow you to identify everything that is using your email domain.
Because reports are written in XML, making sense of them can be tricky, and they can be numerous. dmarcian’s platform can receive these reports and provide visualization on how your email domains are being used, so you can take action and move your DMARC policy towards p=reject.
What is a DMARC Record?
As a mission-driven company, dmarcian is focused on spreading the adoption of DMARC. Because of this, we interface with a wide range of people with varying degrees of knowledge. We thought we’d take a step back and take a look at something fundamental: What is a DMARC record?
A DMARC record is a text entry within the DNS record that tells the world your email domain’s policy when it comes to checking to see if your SPF and/or DKIM has passed or failed.
A DMARC record also tells the servers that touch your email on its way to its final destination to send XML reports back to the reporting email address listed in the DMARC record. These reports provide insight on how your email is moving through the ecosystem and allow you to identify everything that is using your email domain.
More information on publishing DMARC records can be found here.
The DMARC Record; what does it look like?
“v=” indicates this is a DMARC record
“p=” indicates the DMARC policy
“rua=” indicates where data should be sent
RUA is reporting that provides an aggregate view of all of a domain’s traffic. The other option is RUF reports that are redacted forensic copies of the individual emails that are not 100% compliant with DMARC. While RUA reports show the traffic of the email, RUF reports contain snippets from the actual emails themselves. While RUA reporting is all that is needed for DMARC deployment, more advanced users may also add the RUF tag, which will send more sensitive information.
These reports are in Extensible Markup Language (XML), which isn’t easy to read:
There are tools that can translate these XML files into a human-friendly format. Services like Dmarcly, where the RUA reports can be pointed to, automatically process the reports and give you insight via a powerful dashboard to make identifying the valid uses of your email domain easier while disallowing abuse. A dmarcian account will store past reports so you can observe trends and be alerted when new threats arise.
Why Use DMARC for Email?
Email is involved in more than 90% of all network attacks and without DMARC, it can be hard to tell if an email is real or fake. DMARC allows domain owners to protect their domain(s) from unauthorized use by fighting phishing, spoofing, CEO fraud, and Business Email Compromise.
By always sending DMARC compliant email, the operator of an Internet domain can tell the world “everything I send is easy to identify using DMARC—feel free to drop fake email that pretends to be me.”
DMARC’s utility as an anti-spoofing technology stems from a significant innovation; instead of attempting to filter out malicious email, why not provide operators with a way to easily identify legitimate email? DMARC’s promise is to replace the fundamentally flawed “filter out bad” email security model with a “filter in good” model.
If you’re curious about the health of your domain or anyone’s, use this free Domain Checker for a quick check. It inspects DMARC, SPF and DKIM and tells you which actions you need to take to reach compliance.
Benefits of DMARC
If you use email, you’ll benefit by incorporating DMARC.
When strong security controls are deployed against fraudulent email, delivery is simplified, brand reliability increases and visibility is granted to domain owners on how their domains are being used around the Internet.
Security
Security Disallow unauthorized use of your email domain to protect people from spam, fraud, and phishing.
Visibility Gain visibility into who and what across the Internet is sending email using your email domain.
Delivery Use the same modern plumbing that mega companies use to deliver email.
Identity Make your email easy to identify across the huge and growing footprint of DMARC-capable receivers.
Need Help?
If you are interested in a fully managed email security, domain alignment, Dmarc service
Sender Policy Framework (SPF) is used to authenticate the sender of an email. With an SPF record in place, Internet Service Providers can verify that a mail server is authorized to send email for a specific domain. An SPF record is a DNS TXT record containing a list of the IP addresses that are allowed to send email on behalf of your domain.
How does SPF work?
To take advantage of SPF, you publish an SPF record in the DNS. The record is a list of all the IP addresses that are allowed to send email on behalf of the domain.
The SPF mechanism uses the domain in the return-path address to identify the SPF record. When a sender tries to hand-off an email to an email “receiving” server for delivery, the server checks to see if the sender is on the domain’s list of allowed senders. If so, then a link has been established between the piece of email and the email domain. If not, then the server continues processing the email as usual without this link, as any number of things could be going on.
The email might be real, but the list of senders might not be accurate. Real email might have been forwarded which means the email could have come from anywhere and the list of allowed senders doesn’t help too much. Or, the email is fake and unwanted. Too many possible outcomes makes it difficult to attach meaning to the absence of the link that SPF can provide. DKIM fills the gap in the DMARC technical framework as an additional way to try and link a piece of email back to a domain.
What is SPF Format?
More information about how an SPF record is formatted, and how you can create one for your email domain, can be found here: How to Create and Add an SPF Record
Already have an SPF record? We have also developed a comprehensive guide to SPF record formatting to increase your understanding and help troubleshoot any SPF issues that our free SPF Surveyor may bring to your attention: SPF Record Syntax
SPF and DMARC for Email
By itself, SPF can associate a piece of email with a domain. With the DNS records in place, DMARC ties the results of SPF to the content of email, specifically to the domain found in the return path or From: header of an email. For SPF to work correctly in the context of DMARC, the return-path address has to be relevant to the domain of the From: header, which is the item that ties together DMARC alignment.
Why is SPF Important?
SPF has become exceedingly vital to help verify which sending infrastructure can relay email on behalf of your domain. Implementing SPF for email provides major benefits:
Increases domain reputation and email deliverability.
Fights domain impersonation and email spoofing to protect your brand reputation.
One of the foundational methods of email authentication for DMARC.
How do I check my SPF Record?
Check your domain’s SPF settings – dmarcian’s SPF Surveyor is an SPF diagnostic tool that presents a graphical view of SPF records. It allows you to quickly identify which servers are authorized to send on behalf of a domain.
Why SPF-Only Isn’t Safe Enough
Though SPF is a layer of proven email authentication that has been around since the late 1990s, it does have its challenges. Simply put, forwarding of email happens on the Internet and the SPF mechanism doesn’t survive the forwarding process. Forwarding typically happens when you send email to [email protected] and that person has set their email to be forwarded to another address, like [email protected]. In this example, your email appears to be coming out of infrastructure that appears to have nothing to do with you.
DKIM signing can survive forwarding. If your domain is covered with DKIM, dmarcian’s ability to detect forwarding increases. SPF does not work in the context of forwarding, as SPF is simply a list of servers that are authorized to send on behalf of your domain, and it isn’t possible for a domain owner to maintain a list of forwarders.
SPF Misconceptions
Companies often misunderstand how SPF works and instruct their customers to include the company’s own SPF record. However, this ends up doing nothing if the company uses its own domain in the bounce address. When an email receiver processes a piece of email, it will look at the company’s SPF record—not the SPF record of the customer.
Two unwanted things happen because of this misconception:
Unnecessary “includes” are added into their SPF records. This causes SPF records to bloat and introduces management challenges.
Confusion is introduced as people just want to get SPF into place to complete their DMARC deployment. The result is that SPF passes, but DMARC fails.
For SPF to work correctly in the context of DMARC, the bounce address has to be relevant to the domain of the From: header. Unfortunately, many companies that send email on behalf of others do not currently allow their customers to change the bounce address to the customer’s domain. This is slowly changing, but companies first have to understand the basics of how SPF works. We have resources available to help companies send DMARC compliant email on behalf of others.
Note: There is obsolete technology called SenderID that tried to perform SPF-like checks, except it used the From: header domain (among others) as the item to check. SenderID also attempted to reuse existing SPF records, causing even more confusion.
Recent Comments