Welcome to Red Sift’s ultimate technical guide on email protocol configuration. Designed for email security architects and analysts, this comprehensive handbook explores SPF, DKIM, DMARC, MTA-STS, and more, offering insights and practical tips for enhancing your email security posture. 

Beyond addressing common queries and troubleshooting challenges, this guide also offers comprehensive DNS setup instructions for various email service providers. 

As we journey through the chapters, you'll discover the critical role each email security protocol plays, how they collaborate to ensure email authenticity, and actionable strategies to optimize your organization's email security posture.

If you are looking for a less technical, more high-level guide, visit our Email Security Guide, perfect for beginners looking to understand more about email security, as well as buyers who need guidance on how to choose a DMARC vendor.

Designed for email security architects and analysts, this comprehensive handbook explores SPF, DKIM, DMARC, MTA-STS, and more, offering insights and practical tips for enhancing your email security posture. 

Red Sift’s Technical Email Configuration Guide

Introduction

All you need to know about SPF, DKIM and DMARC

In this chapter, we’ve answered some of the most common questions our Customer Success Engineers are asked about SPF, DKIM, and DMARC - the three pillars of modern email authentication. Let’s dive in!

SPF (Sender Policy Framework) is an email authentication standard that was developed to combat sender address forgery. By verifying the authenticity of the MAIL FROM or HELO/EHLO identities during transmission, SPF compares the sending server's IP address against a list of authorized senders specified in a TXT record within the domain owner's DNS. If the sending IP address aligns with the authorized list, SPF authentication succeeds. 

Which part of the email does the SPF protocol focus on?

SPF focuses on the domain found in the email header, known by various names such as Return-Path, MAIL FROM, Bounce address, or "Envelope From". If this header is missing, SPF falls back and looks at the HELO/EHLO hostname and checks for an SPF record there.

The Return-Path header is a technical header that is not visible to the end user - unless they know how to display the headers of an email in their mail client they won't see it. 

DKIM (DomainKeys Identified Mail) is used to sign different header fields and bodies to authenticate the sending domain and prevent message modification during transit.

It achieves this by using asymmetric cryptography which consists of a combination of public and private keys. The private key is private to the sender’s domain and is used to sign the emails. The public key is published in the sender’s DNS so it can be retrieved by anyone receiving messages from the sender.

When an email is composed, its headers and body are signed using the private key of the sender to create a digital signature, which is also sent as a header field along with the email. On the receiver’s side (if DKIM is enabled), the server retrieves the public key and verifies if the email was indeed signed by the sending domain. If the signature is successfully validated that proves that the sending domain sent the message and also that the headers and body of the message have not been modified during transmission.

Which part of the email does the DKIM protocol focus on?

DKIM focuses on the DKIM-Signature header.

As is the case with SPF,  this header is not visible to the end user unless they know how to display the headers of the email they have received.

While DKIM can verify that an email isn't the exact email that was sent, and SPF can recommend that a receiving server should reject an email based on the IP, neither of these are effective at spoofing prevention.

The main reason for this is the header that is checked for each protocol.

SPF checks the record found at the domain in the Return-Path header, and DKIM checks the key found at the d= domain (Found within the DKIM header).

Both of the above protocols can be set to check any domain.

In an email, the major domain of the sender is the domain found in the From header, this header determines the big name at the top of emails - the address that the end-user will see if they check who sent the email.

Given the above, your email domain could be impersonated as attackers could make the From yourdomain.com and the Return-Path and d= theirdomain.com.
Provided the SPF and DKIM records at theirdomain.com were correctly configured, the email would pass both SPF and DKIM resulting in a successfully impersonated domain.

SPF and DKIM have their purposes, but neither alone is enough to prevent imitation.

DMARC stands for Domain-based Message Authentication, Reporting and Conformance and builds upon SPF and DKIM, providing an additional layer of email authentication and policy enforcement. 

It takes into account the results from SPF and DKIM 

For DMARC to pass, it requires SPF or DKIM to pass and for the domain used by either one to also align with the domain found in the From address. If you’re interested in learning more about Identifier Alignment, click here.

It reports SPF, DKIM, and DMARC results back to the domain found in the From address (ie. sender).

Finally, it tells receivers how to treat emails that fail DMARC validation by specifying a policy in DNS.

By setting the DMARC policy to p=reject an organization can recommend to receiving servers to drop any emails set on behalf of their domain that don't pass the alignment check. This will stop all imitation attempts where the receiving server is correctly implementing DMARC.

Which part of the email does the DMARC protocol focus on?

DMARC focuses on the domain found in the From or "Header From" which is visible to the end user. 

Now that we know what headers each protocol looks at, what is contained in those headers, and what is checked?

SPF verifies if an email was sent by an authorized sender by checking a list of authorized IP addresses you publish in your DNS. The receiving server will take the domain found in the Return-Path header and check for an existing SPF record. It checks the SPF record to see if the sending IP address of the email is contained in the SPF record. If the IP address is contained in the SPF record that means that it is authorized to send emails. This means that SPF PASSED. If the IP address is not in the SPF record then SPF FAILS.

If the sending IP address is contained in the SPF record = SPF PASS

If the sending IP address is not contained in the SPF record = SPF FAIL

The receiving server will check the DKIM-Signature header which contains the selector (s=) and signing domain (d=) which are tags used to look up the public key. Once retrieved, the public key is used to validate the email message. If validation is successful then DKIM PASSES and if the validation process is unsuccessful then DKIM FAILS.

If validation is unsuccessful = DKIM FAIL

DMARC (Domain-based Message Authentication, Reporting & Conformance) 

The receiving server will check if either SPF or DKIM PASSED, then it will check if the Return-Path domain used by SPF and/or the d= domain used by DKIM aligns with From domain, and finally, it will extract the DMARC policy published by the domain found in the From address and comply with the policy.

If SPF PASSED and ALIGNED with the From domain = DMARC PASS, or

If DKIM PASSED and ALIGNED with the From domain = DMARC PASS

DMARC not only requires that SPF or DKIM PASS, but it also requires the domains used by either one of those two protocols to ALIGN with the domain found in the From address. Only then will DMARC PASS.

What’s the difference between Strict vs Relaxed alignment?

Strict alignment means that the Return-Path domain or the signing domain d= must be an exact match with the domain in the From address.

Relaxed alignment means that the Return-Path domain or the signing domain d= can be a subdomain of the From address and vice versa.

If you’re interested in learning more about Identifier Alignment, click here.

If DMARC fails, the receiving server would typically comply with the policy that you have specified in your DMARC record.

If you are in report-only mode (p=none) the email will be accepted by the receiving server and scanned by other filtering criteria.

If you are in quarantine mode (p=quarantine) the email will be quarantined and typically sent to the spam folder of the recipient.

If you are in reject mode (p=reject) the receiving server will abort the connection with the sending mail server and the email will never reach the end user.

Irrespective of the policy, the metadata for the email will be logged along with the status of the authentication results and forwarded to your DMARC report processor. Learn more about DMARC reports here.

Make sure that you have an SPF record in your Return-Path domain.

Make sure that you have an SPF record in your HELO/EHLO domain in case of bounces where the Return-Path domain is empty.

Make sure there is a single SPF record per domain.

Make sure that the SPF record syntax is correct.

Make sure that your Return-Path domain aligns with the From domain.

Make sure that your authorized senders are part of the SPF record.

Make sure that unauthorized senders are not in your SPF record.

Make sure that you do not go over the 10 DNS lookup limit imposed by SPF. If you have gone over the 10 DNS lookup limit you will have to consider using a feature such as Red Sift’s OnDMARC’s Dynamic SPF.

Make sure that deprecated SPF record mechanisms such as the ptr mechanism are not used in your SPF record.

Make sure that the sending systems you use support DKIM.

Make sure that the emails are DKIM signed.

Make sure that the signing domain aligns with the From domain.

Make sure that you use a DKIM key size over 1024 bits (a 2048-bit key is advisable)

Make sure, where possible, that the DKIM selectors you choose closely identify the sending service so you can distinguish between them.

Make sure to revoke any keys that have been compromised.

Make sure that the DKIM keys you manage are rotated regularly.

Make sure that the DKIM key syntax is correct.

Make sure that there exists a public key for each corresponding private key that signs your emails.

As DMARC is based on both SPF and DKIM and the domains used by those two protocols, you will have to make sure that the Return-Path domain for SPF is either an exact match or a subdomain of the From domain. The same applies to the signing domain used by DKIM.

Make sure that the DMARC record syntax is correct.

Make sure that you have configured all of your systems correctly with SPF and DKIM before moving to a reject policy as your emails will be lost.

Make sure that you use a system or third-party provider such as Red Sift OnDMARC to receive DMARC reports so that you can make sense of those reports and discover any systems that are misconfigured.

Monitor the status of each of your sending sources and make sure that any changes to SPF and DKIM are identified. Red Sift OnDMARC has this feature as a core part of its product.

We’ve answered some of the most common questions our Customer Success Engineers are asked about SPF, DKIM, and DMARC - the three pillars of modern email authentication.

I have SPF, do I need DMARC to protect my domain? What does DMARC do that SPF does not?

SPF authorizes the sending IPv4/IPv6 addresses.

SPF protects the header of the email that is not visible to the end-user (known as Return-Path, MAIL FROM, "Envelope From", or Bounce address). If this header is missing, the SPF check will be done on the EHLO/HELO address.

SPF does not require any alignment between the From domain and the above-mentioned Return-Path address that it checks, meaning the two don't have to match from an SPF perspective.

SPF does not provide any reporting functionality, meaning the receiver of the email won't send back any reports to the sender, containing results of the email authentication.

SPF does not survive auto-forwarding and indirect mail-flows.

These shortcomings prompted the introduction of DMARC to explicitly tell receivers what to do and provide authentication reports. These reports enabled the sender to take the necessary actions to fix legitimate mail flows.

DMARC makes use of SPF as one of its foundations but also adds additional features as it:

Focuses on the From header which is visible to the end user ("Header From").

Requires that the domain used by SPF aligns (either an exact match or subdomain) with the domain found in the visible From address of the email.

Ignores the nuances of soft fail and hard fail in your SPF configuration i.e. ~all and -all are treated equivalently as an SPF fail.

Provides the reporting functionality to send email authentication results back to the owner of the From so they can find out if their domain is being misused. It also helps with troubleshooting your deliverability as the reporting will aid in discovering any misconfiguration with your legitimate email senders. 

Provides a policy that tells the receivers what to do with an email that fails email authentication. This policy is enforced by the receivers. There is no enforcement when SPF is used without DMARC.

Some mailbox providers have started using visual signs in their mail clients to show if an email is authenticated. For example, Gmail displays a question mark (?) for unauthenticated emails - see the example below.

An include is an SPF mechanism that points to a domain to be queried when checking if the sending IP is allowed or not. If the sending IP is part of the include then it results in a match and SPF passes. 

For example, if you have include:_spf.google.com as part of your SPF record and the originating IP of an email is Google’s IP, it will result in a match as you have authorized Google to send on your behalf and the sending IP is found inside of the include mechanism.

An SPF macro refers to a mechanism used in SPF records to define reusable sets of IP addresses. SPF macros enhance the flexibility and maintainability of SPF records by allowing you to define complex sets of IP addresses in a single mechanism, which can then be referenced within multiple SPF records. This can make it easier to manage large sets of authorized sending servers without duplicating the same information in multiple places.

For example, instead of listing individual IP addresses for each authorized email server in your SPF record, you can define a macro like this:

@spf.salesforce.com IN TXT "v=spf1 exists:%{i}.spf.mta.salesforce.com -all" 


In this example, the macro is the %{i} mechanism, which calls the sender IP of the email. This means the domain becomes something like 233.124.65.65._spf.mta.salesforce.com. 

Managing SPF this way allows you to control a large list of IPs without hitting the SPF lookup limit, and also obscures which IPs you approve for public querying.

The risk with SPF macros is that the majority of legacy email infrastructures do not support them, causing catastrophic deliverability issues. We know from technical studies and our own experience that only about 75% of SMTP servers get macros right.

If an email server does not support SPF macros, the behavior can vary as follows:

If the receiving email server does not support SPF macros, it will not expand or process any macros referenced in the SPF record. Instead, it will treat the macro reference as a literal string. This means that the SPF record effectively loses its intended functionality, potentially leading to incomplete or inaccurate SPF checks. Though macros aren’t used in production SPF records, the no expansion behavior is used in email servers like iCloud. 

Depending on how the SPF record with macros is structured, the lack of macro expansion could result in SPF failures or 'Neutral' results (denoted by the ?all mechanism). In either case, it might not have the desired effect of properly authorizing legitimate sending servers.

If the SPF macros play a critical role in authorizing legitimate sending servers, emails might be more likely to fail SPF checks or be marked as suspicious by email receivers that rely on SPF for authentication.

Learn why you need SPF as well as DKIM and DMARC, what include statements are, and the problem with macros.

Learn more about SPF

An SPF failure occurs when the sender's IP address is not found in the SPF record published. Failures significantly affect the deliverability of your email as they result in the email being sent to spam or discarded altogether. This can be catastrophic for businesses that rely on email to reach customers.

There are two types of SPF failures - SPF softfail and SPF hardfail. A hardfail indicates that an email is not authorized, whereas a softfail means that an email has probably not been authorized. For the email recipient, it determines the treatment of the email; a hardfail tells the recipient to reject the email, whereas a softfail suggests it should be diverted to spam.

We will use two examples to demonstrate the visual difference between both.

In the above example, the minus symbol (in front of all at the end of the record) means that any senders not listed in this SPF record should be treated as a hardfail, ie. they are unauthorized, and emails from them should be discarded. In this case, only the IP address 192.168.0.1 is authorized to send emails and nothing else.

v=spf1 include:spf.protection.outlook.com ~all

In the above example, the tilde symbol (in front of all at the end of the record) means that any senders not listed in this SPF record should be treated as a softfail, i.e. mail can be allowed through but should be tagged as spam or suspicious. In this case, the include:spf.protection.outook.com mechanism authorized Microsoft 365 to send emails. Any emails originating from different servers should be marked as spam by the receivers. 

Given that hardfail ("-all") signals to reject any unauthorized senders not found in the SPF record, it might seem like the mode of choice. However, the decision is more nuanced.

In a pre-DMARC era, SPF records commonly used the "-all" mechanism to strictly enforce sender policies, without the additional layer of DKIM and DMARC to help authenticate legitimate emails.

However, modern guidance now favors "~all" to balance security and deliverability, avoiding unnecessary rejection of valid emails that might fail SPF but pass DKIM and DMARC.

The wider industry echoes that care needs to be taken with SPF modes; the DMARC specification (RFC 7489) states that:

“Some receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.”

For these reasons, we would suggest the following

Use "-all" for inactive, non-email sending domains: Apply "-all" only if the domain sends no emails at all. This setting strictly blocks unauthorized emails but risks rejecting legitimate ones if the SPF record isn’t up-to-date.

Use "~all" for active, email-sending domains: Opt for "~all" if you’re using SPF in combination with DKIM and DMARC to combat phishing and spoofing. This is because “~all” - when implemented in combination with DMARC (at p=reject) - will still reject unauthenticated mail if SPF and DKIM fail. This mode does not block legitimate mail, thus enhancing overall email deliverability.

In summary, softfail strikes a balance between strict security (which might block legitimate emails) and allowing some flexibility in email delivery, ensuring that emails can still be delivered even if there are occasional mismatches in the SPF record.

How is SPF softfail treated by cybersecurity rating companies? 

It is possible that some rating companies may penalize you should your domains be set up with SPF softfail. However, we believe that downgrading a domain's security score based on the presence of a softfail can misrepresent the actual risk profile of the domain and inadvertently penalize organizations that are following industry-recommended practices for responsible email management and security.

On the other hand, rating services like Security Scorecard acknowledge DMARC (when set up in a policy of quarantine or reject) is a “compensating” control for SPF softfail.

If you are penalized for implementing SPF softfail in a cybersecurity audit, engage with the rating company directly to explain your email authentication strategy and its alignment with industry best practices. Advocate for a more nuanced approach to evaluating security postures, one that considers the full context of your email security measures rather than penalizing specific configurations in isolation.

Why SPF isn't enough and you still need DMARC

Irrespective of which failure mode you specify in your SPF record, receiving servers are unlikely to honor your requested policy. This is because SPF is limited in that:

It does not require alignment between the domain in the From field and the Return-Path address it checks. They don't have to match from an SPF perspective.

SPF does not provide reporting functionality, meaning the receiver does not send back reports to the sender containing email authentication results.

SPF does not survive auto-forwarding and indirect mail-flows, which can lead to authentication issues.

Due to these limitations, DMARC (Domain-based Message Authentication, Reporting, and Conformance) was introduced as an additional email authentication standard. DMARC addresses the shortcomings of SPF and provides the following enhancements:

DMARC focuses on the visible From header, which is seen by end-users.

DMARC requires alignment between the domain used by SPF and the visible From address in the email.

DMARC ignores the nuances of soft fail and hard fail in SPF configuration, treating them as SPF failures.

DMARC provides reporting functionality, allowing email authentication results to be sent back to the owner of the From domain. This helps identify domain misuse and troubleshoot any misconfigurations with legitimate email senders.

DMARC includes a policy that instructs receivers on how to handle emails that fail authentication, and receivers enforce this policy. In contrast, SPF alone does not have enforcement mechanisms.

DMARC has gained widespread adoption as an authentication requirement as it overcomes the shortcomings of SPF and DKIM, blocks exact email impersonation, and improves email deliverability.

There are two types of SPF failures - SPF softfail and SPF hardfail. A hardfail indicates that an email is not authorized, whereas a softfail means that an email has probably not been authorized.

SPF failures: Hard fail vs Soft fail

You can rotate DKIM keys by simply replacing the old pair with a new one to authenticate DKIM emails. If a threat actor steals or deciphers your private key, they won’t be able to use it for long if you practice regular DKIM key rotation.

In addition, regularly updating your DKIM keys increases your domain’s email deliverability rate.

It’s generally suggested to rotate DKIM keys every 6 to 12 months. Frequent rotation stops hackers from intercepting and decoding your cryptographic keys. Less frequent rotation (say, once every couple of years) makes your domain more susceptible to the risk of intercepted or decoded keys.

Some DNS editors can receive errors when DKIM keys or other TXT entries are longer than 255 characters.
To resolve this issue, you can enter your DKIM key by breaking it up into pieces on a single TXT entry.

"v=DKIM1; k=rsa; p=abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabc"

"v=DKIM1; k=rsa; p=abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabc"


You can divide them at arbitrary places. The double quote enclosed parts should be separated by a single space character, not a new line.

Canonicalization is a process whereby the headers and body of an email are converted to a canonical standard form before being DKIM signed. This can be thought of as converting data into a standard canonical form.

Some mail systems, such as forwarders, modify emails in transit that can potentially invalidate the DKIM signature applied. While some DKIM signers may accept minor mail modifications, others may be more strict and require stricter canonicalization.

Two canonicalization algorithms have been created to satisfy mild modification to a message and almost no modification to a message before signing. The two canonicalization algorithms are relaxed and simple respectively. 

From DKIM’s perspective, the headers and body of an email are separate and canonicalization algorithms are specified for both, one for the headers and another for the body.

They are represented in the format of canonicalization/canonicalization for the header and body respectively. If no canonicalization is specified then simple is used for both headers and body, so it would look like this: simple/simple.

The simple/simple canonicalization is the stricter of the two and allows for almost no modification to the message header and body. However, this can affect the DKIM signature being invalidated by some forwarders as the email passes through them. Many of the issues with DKIM being invalidated during forwarding can be solved if the canonicalization is changed to relaxed/relaxed to allow for mild modifications to the emails.

A DKIM selector is a string that points to a specific DKIM public key record in your DNS. It is specified as s= tag in the DKIM-Signature header field and can be found in the technical headers of an email.

Validation on the receiver side uses the selector in combination with the signing domain in order to carry out a DNS query and find the public key in your DNS. 


When the receiver retrieves the public key it uses it to verify the DKIM signature.

No two services should use the same selector. For example, if you are sending emails from a number of services on behalf of your domain such as Google, Mailchimp, Salesforce, and Sendgrid, each one must use a unique key and selector in your DNS. If the selectors were the same the recipient would not be able to tell which key to use to decipher a particular email. 

Generating 2048 bits DKIM public and private keys using OpenSSL on a Mac

Learn how to generate 2048 bits DKIM public and private keys using the Mac terminal and create a DNS record.

How to generate the private and public keys

To generate a private key type: openssl genrsa -out private.key 2048

To generate a public key from the private key type: openssl rsa -in private.key -pubout -out public.key

Find the folder that contains your public key and open it. It should look something like the image below.

Manually convert the highlighted text above to a single line ie. remove the spaces between new lines.

The generated 2048-bit DKIM public key is too long to fit into a single TXT DNS record. A DNS record can be up to 255 characters. Therefore your public key will need to be split into two separate TXT records using quotes and slash or brackets and quotes as shown below. 

To create the DNS record you will have to specify the Name, Type, and Value of the DNS record.

The DNS record Name will look like this: 


Where the selector is defined by you and can be called anything, for example, the date, device, or service that will sign the emails.

The DNS record Value should look like the examples below. The part in bold is copied from the generated public key file and remember that you will need to split the public key into two records.

“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmC”

“Lrt5j82yBC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB”

(“v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlTtO1qRFaK955gz16Y8c1EMCqtaT4exCrwfor2yT438ZVjrUcqo2tPUNR4eqkD+xcKRQnWSw931uVUY6YJWtOrgrXTIrHnTkf5Xtg+jaXr0OhjdeVDIG/Le7oOVWncMf+9J4ZSRybOpb+XZPp/JLjis6pmC”

“Lrt5j82yBC9DCbsEPSOVVOC1mr5lq8irQs+qAv6M/DnjNcUrdiRBJyNrs2lfuvfs8BFceZAk1AwcVBcYCmZl5OkxZBn8liTC34FPJLLHm6jMp9+c0OaEtxo8zr3QX0ZYEWC3XqZ/p9fo4Pcg+fpyjee79wBVqUzhVAWdzE5+qAIn4e1Dmslyb6IX4mwIDAQAB”)

Learn why you need DKIM as well as SPF and DKIM, what DKIM key rotation is, and get tips on technical configuration.

Learn more about DKIM

A DMARC TXT record is a text entry in the DNS that instructs the worldwide email servers about your DMARC policy. It also contains information about whom to send XML reports to tell how your email is proceeding through the ecosystem. You must monitor these DMARC reports to detect unidentified and suspicious activities attempted using your domain name. 

A usual DMARC TXT record looks like this:

v=DMARC1; p=none; rua=mailto:example@xyzdomain.com;

v (version tag) represents the version of the protocol, and currently, there’s only one version. So, the value is always v=DMARC1

p (policy tag) shows the domain policy (none, quarantine, or reject) to recipients’ email servers to direct how to treat emails failing SPF and DKIM checks

The rua tag contains a comma-separated list of email addresses defining where receivers should send aggregate reports

An example of a DMARC record might look like this:

v=DMARC1; p=reject; pct=100; rua=mailto:1234@inbox.ondmarc.com,mailto:dmarc@example.com; ruf=mailto:1234@inbox.ondmarc.com,mailto:dmarc@example.com;

The policy shows that 100% of failed emails should be rejected. It also shows where the aggregate and forensics reports should be sent to.

See the table below for a description and example of each tag that could appear in a DMARC record.

Tags and descriptions that could appear in a DMARC record

SPF validates the MAIL FROM/Return-PATH domain (or the HELO/EHLO hostname if MAIL FROM is empty) and DKIM validates the domain specified in the d= field of the DKIM headers. If any of the above validates then that means a PASS.

However, DMARC goes a step further as it does not only require SPF or DKIM to PASS but it also requires at least one of the domains used by SPF or DKIM to align with the domain found in the From header. 

In the case of SPF, identifier alignment means that the MAIL FROM/Return-PATH check has to PASS and also the domain portion of the MAIL FROM/Return-PATH has to align with the domain found in the From address. In cases where the MAIL-FROM is empty (found with bounces), alignment is checked against the EHLO domain.
In strict alignment, the domains have to match exactly, whereas in relaxed alignment subdomains are also allowed as long as they come from the same organizational domain. 

MAIL-FROM/RETURN-PATH: @ondmarc.com​
From header: @knowledge.ondmarc.com

In the above example, if DMARC was set to strict SPF mode then an email coming from knowledge.ondmarc.com would pass SPF but DMARC would fail as the domains do not match exactly i.e. they are not aligned. However, in relaxed alignment mode, DMARC would pass.

In the case of DKIM, identifier alignment means that the domain specified by the d= field of the DKIM headers has to PASS and align to the domain found in the From header. Again, in strict alignment, the domains in the d= field and From header have to match exactly whereas, in relaxed alignment, subdomains are also allowed as long as they come from the same organizational domain.

d= "ondmarc.com"
​From header: @knowledge.ondmarc.com

In the above example, if DMARC was set to strict DKIM mode then an email coming from knowledge.ondmarc.com would pass DKIM but DMARC would fail as the domains do not match exactly ie. they are not aligned. However, in relaxed alignment mode, DMARC would pass.

A DMARC aggregate report contains information about the authentication status of messages sent on behalf of a domain. It is an XML feedback report designed to provide visibility into emails that passed or failed SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

The report provides domain owners with precise insight into:

The effect of the domain owner’s DMARC policy

The domain or organization that sent the report

The domain that you are receiving the report for and its current DMARC policy

The disposition of those emails ie. the policy that was applied to those emails by the receiver

How do the recipients of my emails know where to send the aggregate reports?

The recipients of your emails will look at the rua tag of your DMARC record and send the reports there. 

Find out about DMARC records, aggregate DMARC reports, forensic reports, how DMARC protects subdomains, and much more.