FAQ: DMARC for Email Service Providers (ESPs)

Get all your DMARC FAQs answered in this DMARC FAQ guide for email service providers (ESPs).
faqs on dmarc

There are a lot of questions surrounding DMARC. What is it, how does it work, and why do you need it—those top the list. However, there are other DMARC FAQs. For example, do DMARC policies get inherited by subdomains? What is the SPF domain lookup limit?

Have you asked similar questions? You’re not alone.

Fortunately, you’re in the right place.

In this DMARC FAQ guide, we answer all the burning questions you have (and will soon have) about DMARC, DKIM, and SPF. If you have a specific question you need answered, click one of the links below to jump to that FAQ.

What is DMARC?

DMARC—Domain-based Message Authentication, Reporting, and Conformance—is an open email authentication standard sending domains use to block fraudulent emails. DMARC is built on top of two earlier standards—SPF and DKIM—and adds additional features like reporting, policy definition, and the notion of identity alignment.

Does DMARC stop phishing?

When configured correctly, DMARC can completely stop phishing attacks in which the attacker sends an email with a “From” address that appears to originate from a protected domain. As this is the primary form of phishing attacks, DMARC is a very effective tool to defend customers, employees, partners, and others from phishing.

Does DMARC help deliverability?

Large-scale email receivers, such as Google, Microsoft, and Yahoo!, are increasingly requiring that email messages be properly authenticated in a DMARC-compliant way. Adding a DMARC record for a domain, in conjunction with adequately configured SPF and/or DKIM records, will help ensure proper delivery.

Furthermore, the proper use of DMARC ensures that messages sent by spammers using a sender’s domain will not negatively impact the domain’s overall reputation. Such spam will be blocked, and the sender’s brand will be protected.

What does DMARC add to existing email authentication standards like SPF and DKIM?

DMARC contributes three major elements to previously existing email authentication standards:

  • Reporting: DMARC-participating receivers agree to provide email authentication reports to sending domains. This allows the owners of these sending domains to understand the current state of email authentication for their domain, see legitimate services that may not be properly authenticating, and identify sources of domain abuse.
  • Policy: With DMARC, sending domains can recommend how a receiver should treat an email that fails authentication rather than leaving it to the receiver’s discretion. This allows sending domains to authenticate all sources of legitimate email over time rather than requiring domain owners to fix all authentication issues immediately. A report-only policy of “p=none” can be useful during this investigation phase, but domain owners should strive to reach an enforcement level of “p=quarantine” or “p=reject”.
  • Identity Alignment: There are multiple sources of identity in an email message (including the From address, DKIM signature identity, and Return-Path address). DMARC prioritizes the human-readable From address as a source of identity and only considers authentication results for identities aligned with this From address. SPF and DKIM use different sources of identity. So the authentication they provide will only prevent fraud if their source of identity matches the human-readable From address in some way.

Valimail makes getting to DMARC enforcement easy. You can sign up for our Enforce product, and we’ll help you point your DMARC, SPF, and DKIM to Valimail. This is the last time you’ll ever need to make any DNS updates.

how valimail helps with dmarc

What are the different policy levels defined by DMARC?

DMARC defines three policy levels that describe how receivers are supposed to handle email failing authentication. These levels are “p=none”, “p=quarantine”, and “p=reject”.

  • none: Receivers are instructed not to change how they deliver email based on email authentication failures. The “none” level is typically used when domain owners initially authenticate their email services; moving beyond this level is key to enabling DMARC to stop fraud.
  • quarantine: Receivers are asked to mark messages failing authentication as spam.
  • reject: Receivers are requested to block messages failing authentication entirely and not deliver them to their intended recipients.
dmarc policy graphic

In all cases, the policy is enforced by the system receiving the email, and the receiving system may choose to handle email delivery differently than the DMARC policy prescribes. For example, Microsoft Office 365 treats “quarantine” and “reject” identically.

What is identity alignment?

Email messages typically include multiple sources of identity, each of which may be associated with a different domain. Some of these include:

  • Human-readable From address (RFC 5322.from, pra)
  • Return-Path address (RFC 5321.from, mfrom)
  • Zero, one, or more identities associated with DKIM signatures of the message
  • Reply-To address
  • Sender address

DMARC is primarily an anti-fraud standard, focusing on the identity displayed to the recipient: the human-readable From address. The domain in the From address is the one authenticated by DMARC.

SPF and DKIM each authenticate a different source of identity than the human-readable From address. So SPF or DKIM authentication alone will not provide the level of anti-fraud protection to which DMARC aspires.

Instead, DMARC will only consider an SPF or DKIM authentication result if the domain authenticated by SPF or DKIM matches the domain in the human-readable From address. In this situation, the identities are considered “aligned.”

In cases where SPF or DKIM authenticates with an identity whose domain doesn’t match the domain in the human-readable From address, the non-matching authentication result is discarded. DMARC does not cause any change in the underlying SPF or DKIM behavior and the corresponding identities against which they authenticate.

So passing SPF or DKIM isn’t enough to ensure that a message passes DMARC?


It is very common to see messages that pass SPF and/or DKIM but fail DMARC because of identity misalignment.

This is a common point of confusion, and many resources on the web get it wrong. Understanding how identity alignment works with SPF and DKIM is crucial to making DMARC work.

What are organizational domains?

To support flexible domain matching, DMARC introduces the concept of an organizational domain. Typically, this is the top-level domain (TLD) plus one more label. For some countries that use second-level domains to categorize organizations, the organizational domain is this second-level domain plus one more label.

These are all organizational domains:

  • nytimes.com
  • bbc.co.uk
  • Wikipedia.org

And the following domains all share the same organizational domain (bbc.co.uk):

  • mail123.bbc.co.uk
  • abc.def.x-y.bbc.co.uk
  • bbc.co.uk

How does DMARC use organizational domains for identity alignment?

In the most common (“relaxed”) configurations, DMARC authentication does not require an exact match between the domain from the human-readable From address and the domain used in the SPF or DKIM identity. In this mode, DMARC only requires that the organizational domains match.

While it is possible to set DMARC records to require exact matches (“strict”), this is generally unnecessary for security reasons. Because it is extremely common for organizations to use multiple subdomains for sending email, configuring DMARC to require exact matches is usually ill-advised.

How do domain owners configure DMARC for their domains?

DMARC is configured through the use of DNS TXT records. A domain owner adds a special DNS TXT record on the “_dmarc” subdomain of the domain for which they’d like to configure DMARC. This DNS TXT record defines the policy for the domain.

Do DMARC policies get inherited by subdomains?

Yes, but only from the organizational domain.

The DMARC standard defines a lookup rule for DNS records, which explains how the relevant DMARC policy DNS record is determined. The rule is as follows:

  1. Extract the email domain from the human-readable From address.
  2.  Look up a DMARC record on the “_dmarc” subdomain of the email domain.
  3.  If a record is found, use that record to determine the DMARC policy and terminate the lookup process.
  4.  If no record is found, and the email domain is not an organizational domain, look up the “_dmarc” subdomain of the corresponding organizational domain. If a record is found on this subdomain, use that record to determine the DMARC policy.
  5.  If no record is found, then the process terminates, and DMARC is not enforced for the message.

A key takeaway from this process is that defining a single DMARC record on the organizational domain is generally sufficient. Even if an email service provider or domain owner uses a subdomain to send email, they don’t need to create separate DMARC records for each subdomain.

In certain circumstances, this lookup rule can lead to non-intuitive behavior. For example, consider emails sent from the domain “abcd.xyz.example.com”. The lookup rule means that the receiver will potentially look for a DMARC record on the following domains:

  1. _dmarc.abcd.xyz.example.com
  2. _dmarc.example.com

A DMARC record on _dmarc.xyz.example.com will be ignored and won’t apply to this email.

What is the “sp” attribute in a DMARC record? Do I need to set it?

The “sp” attribute is the subdomain policy, and it defines the way DMARC behaves for subdomains of the organizational domain, provided that the subdomain doesn’t have a DMARC record explicitly defined.

Because of how DMARC records are looked up from subdomains, the “sp” attribute only affects behavior when it is defined on the organizational domain. If this attribute is defined on a subdomain’s DMARC record, it will have no effect.

In most cases, domain owners should not set an “sp” attribute.
If an email service provider manages a dedicated subdomain, you should not set the “sp” attribute on the subdomain record.

What does a DMARC DNS record look like?

There are only four attributes found in most DMARC DNS records. These are:

  • v — “DMARC1” for the current DMARC revision. This attribute must appear first.
  • p — Specifies the enforcement level requested by the sender. Allowed values are “none,” “quarantine,” and “reject.” This attribute is required and must be the second attribute in the record.
  •  rua — A comma-separated list of URLs for aggregate report delivery. These are typically “mailto” URLs. This attribute is optional.
  •  ruf — A comma-separated list of URLs for forensic/failure report delivery. These are typically “mailto” URLs. This attribute is optional.

A sample DMARC record, for example.com might be:

v=DMARC1; p=quarantine; rua=mailto:dmarc_agg@vali.email; ruf=mailto:dmarc-reports@example.com

If you’d like a more complete discussion of the DMARC record syntax, please consult the RFC here.

What is Sender Policy Framework (SPF)?

Sender Policy Framework (SPF) is an open, DNS-based email authentication system that allows sending domains to define which IP addresses are allowed to deliver email to receiving mail servers on behalf of the domain.

On which domains do receiving mail servers look up the SPF record?

An email message contains several domains that could be used to look up the SPF DNS record. The SPF standard specifies that only two possible domains should be used to look up the SPF record. These domains are:

  • The domain specified in the Return-Path address
  • The domain used is specified in the EHLO / HELO SMTP command by the delivering mail server

Typically, only the first of these two options is used.

It is important to understand that the domain in the human-readable From address will not be used for SPF record lookup unless it matches one of the two domains listed above. This has important implications when SPF is being used for DMARC.

What does an SPF DNS record look like?

Here’s an example of a simple SPF record authenticating a single service:

v=spf1 include:_spf.google.com –all

Here’s an example of a more complex record, with additional services and some dedicated IP addresses:

v=spf1 include:spf.protection.outlook.com include:mail.zendesk.com ip6:2001:db8::/32 ip4: –all

What is the SPF domain lookup limit?

As part of evaluating whether an email message passes SPF authentication, a receiving mail server may have to make one or more DNS lookups. Typical situations where such a lookup might be required include:

  • When evaluating an “include” directive to pull in the SPF rule defined on another domain
  • When checking an IP address against an “a,” “mx,” or “ptr” directive — which require an A, MX, or PTR DNS lookup, respectively, to evaluate

To protect receiving mail servers from denial of service attacks, the SPF standard includes a hard limit on the number of domain lookups such a server is permitted to make when evaluating whether an email message passes SPF. That limit is 10 lookups.

Can you provide some examples of how to calculate the domain lookup count for an SPF record?

Let’s start with the SPF records published by Google for use by its customers.

Google asks its customers to include the SPF record _spf.google.com in their individual domain SPF records. Looking up the contents of this record in DNS, we find:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

with each of the included _netblocks SPF records simply consisting of a list of IP addresses, and hence requiring no additional domain lookups.

Now consider a domain with an SPF record that only includes the Google-recommended record:

v=spf1 include:_spf.google.com ~all

will have a domain lookup count of four — one for the _spf.google.com lookup, and one for each of the _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com domains.

Now imagine you want to include the records provided by a number of other email service providers. The contribution to the domain lookup from each included record can be calculated in a manner analogous to the _spf.google.com. The total domain count of the resulting record is just the sum of the individual contributions.

For example, if mailgun.org includes two other domains in its SPF record, then the following record:

v=spf1 include:_spf.google.com include:mailgun.org ~all

will have a total domain lookup count of 7.

If a domain owner were then to add an “a” and an “mx” directive to the SPF, like so:

v=spf1 a mx include:_spf.google.com include:mailgun.org ~all

then each of these directives would contribute one to the domain lookup count, and the total count for this SPF record would be 9.

When does the SPF domain lookup limit matter?

Most email service providers publish an SPF record in DNS for use by their customers. These customer-centric SPF records frequently include other domains or have additional directives requiring domain lookups, so their total contribution to the lookup count may be much more significant than 1.

Customers are then instructed to ensure that the SPF record published on their own domain has an “include” directive referencing the domain on which the email service provider published their SPF record.

Unfortunately, this makes it very easy for domain owners to run into the SPF domain lookup limit. It is not uncommon, even when using 2–3 services, for sender domains to reach a domain lookup count that exceeds the SPF lookup limit.

It’s also not necessarily obvious when the SPF domain lookup limit has been exceeded. SPF records consist of a set of rules, each one evaluated sequentially. So if a message is validated by one of the rules defined early in the SPF record, the message will authenticate even though the SPF record as a whole is broken. Messages which are intended to be authenticated by rules that appear later in the SPF record will fail because the receiver will only evaluate the record after it reaches those rules.

Domain owners should endeavor to limit the number of includes in the SPF records for their domains to help ensure that they don’t exceed this limit. And email service providers should not recommend or require domain owners add an “include” directive unless absolutely necessary.

What do I need to do to authenticate messages I send with SPF in a DMARC-compatible way?

What you need to do depends on how you are handling bounce messages.

I don’t need to intercept bounce messages.

In this case, use the message’s From address for the Return-Path address. Publish an SPF record with your mail servers that your customers can include in their domain’s SPF record.

I need to intercept bounce messages, and I can use a customer’s subdomain in my Return-Path address.

In this case, your customer has delegated a subdomain of their domain to you using either a CNAME or NS record. You should use this subdomain in the Return-Path address for messages you send on their behalf. Publish an SPF record on the domain that includes the IP addresses of the mail servers sending email on the customer’s behalf.

I need to intercept bounce messages, but I can’t use a customer’s subdomain in my Return-Path address.

In this case, SPF cannot be used to authenticate messages in a DMARC-compatible way. Instead, you should use DKIM to authenticate your messages.

What is Sender-ID, and how is it different from SPF?

Sender-ID is an obsolete alternative email authentication standard similar to the SPF standard but with a few crucial differences.

Sender-ID reused DNS records initially defined for SPF and interpreted them somewhat differently as part of its operation. The most significant difference between SPF and Sender-ID is how the two standards determined which domain(s) to use to determine the SPF rule to apply to the message. Because the lookup process differs between the two standards, messages that authenticate with SPF may not authenticate with Sender-ID and vice versa, even though all DNS records are the same.

As described above, SPF uses the domain from the Return-Path address to determine the DNS record containing the relevant SPF record. Sender-ID may use this address (called the mfrom in Sender-ID parlance), the human-readable From address (called the pra in Sender-ID parlance), or both to determine whether a given message is properly authenticated.

The implications of this difference in behavior have caused considerable confusion in the email authentication world.

Do I ever need to configure SPF on a domain that is not used by the Return-Path?


Because Sender-ID reused existing SPF records, there is a common belief that sending IPs needed to be authenticated by the domain in the From address, usually the customer’s apex domain. As Sender-ID is obsolete and no longer used by major receivers, this is no longer a good recommendation.

Many email service providers still recommend that their customers add an include directive to the apex domain SPF record, even if the email service provider uses another domain for the Return-Path. You should revise your recommendations if you are an email service provider.

But adding a directive to the apex domain SPF record can’t hurt, so why should I change our recommendation?

Adding extraneous directives to a customer’s apex domain SPF record can, and often does, break authentication for some of their email services. Any domain-resolving directives in the apex domain SPF record, or pulled into the record via includes, will contribute to the number of domain lookups done by a receiver when evaluating SPF for a message. SPF has a hard limit of 10 lookups.

Adding an unneeded directive to the apex domain SPF record can push your customer’s SPF record over the 10-domain lookup limit. This breaks authentication for the domain and, depending on the details, may break authentication for one or more services in use by the domain.

Inclusion in the apex domain SPF record should be reserved for internal systems and external services that use the apex domain in the Return-Path of the messages they generate.

Do I still need to configure dedicated Sender-ID (v=spf2.0) records?

Sender-ID records are DNS TXT records starting with “v=spf2.0”. These should not be confused with SPF records, which start with “v=spf1”.

As Sender-ID is now an obsolete standard, there is no longer any need to configure Sender-ID DNS records or to ask your customers to configure such records.

If you have any Sender-ID records currently set in DNS, you may wish to remove them.

What is DKIM?

DKIM (DomainKeys Identified Mail) is an open, DNS-based email authentication standard that uses public key encryption to authenticate email messages.

Message originators generate a hash of the email message, encrypt that hash using a private key, and include the encrypted hash (the cryptographic signature) as a header in the message. That signature is also associated with a DNS domain (included in the mail header with the signature).

The public key corresponding to the private key is published under a specific subdomain of the DNS domain used in the signature. Because only the domain owner (or someone they authorize) should be able to publish a DNS record for the subdomain, this associates the public key with the domain owner.

When a mail server receives a DKIM-signed message, it looks up the public key in DNS. The mail server uses the public key to decrypt the signature included in the email header. The mail server then computes a hash of the incoming message using the same algorithm as the message originator. If the computed hash matches the decrypted signature, then the message is authenticated. Otherwise, it fails DKIM authentication.

What is a DKIM selector?

To support many DKIM key records for a single domain, the DKIM standard introduced the notion of a selector. A selector is simply a sequence of one or more DNS domain labels. The selector is included as a field in the DKIM message header.

A receiving mail server uses the selector and the domain included in the DKIM message header to determine the exact domain to be used to retrieve the DNS record containing the public key. The DKIM record domain is constructed as follows: ._domainkey.

For example, if a DKIM signature has a selector abcd.xyz and a domain of example.com, then the corresponding DKIM record domain would be abcd.xyz._domainkey.example.com.

Can I use a single key, using a single shared domain, to authenticate all of my customers?


A single key on a shared domain can allow your messages to pass DKIM. But in today’s world, this is no longer sufficient because DKIM authentication by itself does nothing to stop fraudulent emails. It’s easy for phishers to use DKIM to authenticate messages against their own domains while displaying a human-readable From address from another domain. This is precisely the abuse DMARC was designed to stop.

Because DMARC requires that a DKIM signature domain aligns with the message’s From domain, if you are using a customer’s domain in the From address, a shared domain DKIM signature will not allow the message to pass DMARC.

So my customers need to insert one or more DNS records to allow my messages to authenticate with DKIM?


If you wish to authenticate messages with DKIM, the public key record corresponding to the private (signing) key must be in DNS on an appropriate subdomain of your customer’s domain. Your customer may insert this value directly as a TXT record or can delegate it to you or another third party via an NS or CNAME record.

Can I share DKIM keys between customers, as long as they have a DNS record (TXT or CNAME) with the key in their DNS?

Yes, this is technically allowed. But it has serious security implications and should be avoided.

When sharing a DKIM key between customers, an attacker who gets access to the signing key will be able to send fraudulent emails as any of your customers.

This decision requires even more consideration if your customers are using DNS TXT records for their DKIM key records rather than CNAMEs to records that you can update. Customers must update or remove the DNS TXT records to block these fraudulent emails in this situation.

How frequently do I need to change the DKIM keys I’m using to send email on behalf of customers?

There is no hard and fast rule for how frequently you need to change (or “rotate”) the DKIM keys being used to sign messages. But, that said, frequent rotation of DKIM keys is the single most effective measure you can take to increase the security of DKIM authentication. So updating at least once a year, preferably more frequently, is strongly advised.

If I change my DKIM keys, won’t that break messages that may be in transit and haven’t hit the receiver’s inbox?

Under some circumstances changing a DKIM key record can cause messages signed with the original DKIM key to fail DKIM authentication. This can happen if the DNS record with the public key is changed.

How can I avoid breaking authentication for my messages when rotating my DKIM keys?

The standard solution to this problem is to use multiple selectors for your DKIM signatures, and only change one at a time. This allows you to rotate DKIM keys without breaking any in-transit messages that their receivers may not have yet processed.

For example, you could have your customer set up two DKIM key DNS records in their domain, not just one, with selectors “s1” and “s2”. You sign messages with both the “s1” and “s2” keys, generating two signatures on the message. When updating the “s1” DKIM key, that signature would fail to verify in some circumstances, but the “s2” DKIM signature would continue to verify, authenticating the message.

At a later time, when updating the “s2” DKIM key, you would leave the “s1” DKIM key constant, and a similar process would occur.

What key size should I use for my DKIM keys?

At a minimum, you should be using 1024-bit keys. Google and some other receivers consider keys smaller than 1024 bits insecure, and will not use them for authentication.

Many cryptographers feel that a key size of 1024 bits will likely become insecure sometime in the next few years. You may wish to consider a larger key size (e.g., 2048), which is likely to be secure against cryptographic attacks for the foreseeable future.

What about ADSP, SSP, and other email policy standards? Are they relevant for DMARC?

DMARC is primarily intended to replace earlier standards that defined email authentication policy. As an email service provider, you should not need to configure ADSP or SSP records or require your customers to do so.

Get to DMARC enforcement today

This is a lot of information, and we know it can seem exhausting to figure it all out on your own. That’s why we’re here to make it easy for you.

As experts in DMARC, we have the tools and resources necessary to get you to DMARC enforcement and help you maintain it.

All you need to do to take the first step is sign up for a free account on our Monitor platform. You’ll be able to see statuses on your DMARC enforcement, as well as who’s sending mail as your domain.

how valimail helps with dmarc enforcement

From there, we’ll be able to walk you through the rest of the steps to get your domain to enforcement.

Get started for free
with Monitor

Start your path to DMARC enforcement with a panoramic view of the traffic being sent on your behalf.
No trial offers, credit cards, or obligations.

Explore all Valimail
has to offer

Go one step further than visibility…Take action! Reach DMARC enforcement faster. Stay compliant with evolving sender requirements. All while protecting your brand.

Phishing and BEC protection starts with your domain — verify your DMARC status with the Valimail Domain Checker.