FAQ - DMARC Wiki (original) (raw)

Aggregate reports are usually generated once a day. After you publish a DMARC record in the DNS, allow at least 24 hours to receive your first report. Please note that such reports will only be generated if messages using your domain are sent to a given DMARC receiver during this period. If you haven’t received a report by the second day after publishing, you may want to send a test message to an address managed by a known-active DMARC receiver.The following DMARC record in the DNS for example.com will tell receivers to start generating aggregate reports without changing the disposition of your emails and to send them to the related postmaster email.

A common error is to not include mailto: as part of the email address. Check the syntax of your DMARC record.

If you indicate that reports should be sent to an address outside your domain, you may need to request that the receiving party publish a special DMARC report DNS record:

Reports can be huge, although many sites will limit them to 10 megabytes. They contain a record for every connecting IP and could contain any combination of DKIM and SPF validation with any envelope mail from domain. This could be huge if you are the target of phishing. Be prepared to be able to receive a 10 megabyte report at any time, even if you generate much smaller reports from your valid mail.

As a precautionary measure, if you want to receive aggregate reports, please ensure your anti-spam filters and mail server accept large attachments of type ZIP and attachments with names that include “.com”. It is common to use regex type filtering rules to reject emails that contain certain types of attachments or contain names that might be executables. If after at least 24 hours you have not received a report, check your logs and consult your system documentation to ensure the rules are complete and correct.

Why are the semicolons escaped in DMARC records? Should I do the same when I publish a DMARC record?

When you query a DMARC record you often see results like this:

$ host -t TXT _dmarc.dmarc.org _dmarc.dmarc.org descriptive text "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"

$ nslookup

set type=TXT _dmarc.dmarc.org Non-authoritative answer: _dmarc.dmarc.org text = "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"

$ dig +short txt _dmarc.dmarc.org "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"

This makes people want to put backslashes into their records. You do not need to do this; those backslashes are not part of the record, and are added by the command that does the query.

When you enter the DMARC record in the zone file for your DNS server, just put in the semicolons unquoted.

_dmarc IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:reports@dmarc.org; ruf=mailto:reports@dmarc.org"

If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

Do I want to receive Failure Reports (ruf=)?

Not until you have read this answer and made sure you are ready to receive a LOT of messages...

Failure reports are very useful for forensic analysis to help identify both bugs in your own mail sending software and some kinds of phishing or other impersonation attacks, but... a failure report is sent immediately, every time a receiver rejects a message due to your DMARC policy. The receiver may even send a report if the mail is accepted but one of the authentication mechanism does not pass the alignement test. A forensic report can be a complete copy of the rejected email in Abuse Reporting Format (ARF). You may think your sending practices are good, and there should be few emails rejected, but every email that spoofs your domain will be rejected too and you are asking to get a copy. This could be several times the volume of your legitimate emails. So no, you do not want to receive Failure Reports until you are well prepared for them.

The strategy we recommend is to first publish a simple record in monitor mode (i.e. “p=none”) just to get aggregate reports.

_dmarc.example.com IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:dmarc-rua@example.com"

Study the aggregate reports, understand your mail infrastructure, understand what would happen if you change the policy to reject, especially how many failure reports you are likely to receive. Once you are confident, add the “ruf=” tag pointing to a different mailbox than the rua= tag points to. If you get too many failure reports, this will not fill up the aggregate report mailbox, so you can keep your statistics running.

_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com"

My organization uses third-parties senders, how can I get them DMARC compliant?

There are several options to set up third party senders so the emails they send are not rejected by your DMARC policy. Which option you choose will depend on the capabilities of the third party sender and how much you want their emails to be part of your reputation.

  1. Integrate externally: The third party sender uses its own mail servers to send your emails.
    1. Delegate a sub domain so they can put their own DKIM record and SPF record in the DNS. The third party sender does not need to publish a DMARC record as your record under the organization name will cover it. Note: you need to make sure they do not add a DMARC record that goes against the policy of your organization domain.
    2. Give the third party a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP, maybe via a SPF include, to your SPF record. Note: ensure the DKIM key pair is specific to the third party so it can be revoked easily. Ensure that when you include their SPF in your SPF, you are not adding a large block of sending IPs, or other third party infrastructure.
  2. Integrate internally: Get the third party sender to relay all your emails via your mail server. Note: Ensure the envelope from is correct, and ensure you are not creating an open relay on your side.
  3. Do not integrate and tell them not to spoof: Ask the third party sender to use their own domain in the From: header and if replies are required, either have them to alias this email back to you, or have them set the Reply-To: header to one of your email address. NOTE: In this case, the forwarding must not break DKIM or you risk rejecting the replies based on the replier’s DMARC settings.

I published my DMARC record, but I am not receiving DMARC failure/forensic reports. Why?

To receive failure reports that you can use for forensic analysis, you must have a “ruf” entry that points to one or more valid email addresses. These addresses must be in the same domain as your organization domain, or you must publish a DNS “report” record, to authorize the reception of reports from this domain.

DMARC Record:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com; ruf=mailto:auth-reports@thirdparty.example.net"

Report Authorization Record:

example.com._report._dmarc.thirdparty.example.net. TXT "v=DMARC1"

Be aware that you may receive a lot of failure reports, so you should only publish a “ruf” after you have used aggregate reports to determine how many failure reports you are likely to receive.

Not all receivers send failure reports, so you may not receive failure reports, or you may receive fewer than you would expect. Due to the variety of laws governing data sharing that vary across many jurisdictions, whether or not to implement failure reporting is ultimately up to the discretion of the receiver. The standard allows receivers to send aggregate reports without also sending failure reports.

I published a DMARC record with reports going to another domain, but none seem to be received

To receive DMARC reports, you must have "rua" and/or “ruf” tag in your DMARC record. If the addresses in those tags are in a different domain from the one the record is published in, there needs to be an "external reporting authorization" record in the target domain. Here's an example of a DMARC record where both the "rua" and "ruf" tag have addresses in a different domain:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:a-reports@otherdomain.com; ruf=mailto:f-reports@otherdomain.com"

The DMARC specification describes the need for these authorization records in Section 7.1, Verifying External Destinations. Following the details of that section, the owner/operator of otherdomain.com would have to publish a DNS record like the one below to signal that it is willing to accept reports generated for the domain example.com:

example.com._report._dmarc.otherdomain.com. TXT "v=DMARC1"

Multiple domain owners who wish to direct all their reports to mailboxes in one domain will need to publish external reporting authorization records accordingly.

It is possible for a domain owner to use DNS wildcard records to authorize or accept reports for any domain. Please see this FAQ entry for an example of how to do this, but be aware that you will be signalling to report generators that you will accept reports meant for any domain, which bad actors may try to exploit.

What steps should I follow to implement DMARC on my corporate email domain?

Your individual situation may vary, but here is a quick recipe that works for some organizations. These steps are in chronological order.

  1. It does not matter if you have SPF or DKIM deployed, just publish a DMARC record with “p=none” and a “rua=” pointing to a special mailbox to receive aggregate reports. NOTE: Do not put a “ruf=” at this point as it may overwhelm your server and it isn’t needed, yet.
  2. Read the aggregate reports, understand your email infrastructure, and get at least one of SPF or DKIM to work correctly for all mail you care about.
  3. If you use third party providers to send mail on your behalf, get them to be DMARC compliant (see this FAQ).
  4. Once you know that your infrastructure is mostly correct and you can predict the approximate number of failure reports you will receive, you can decide whether you would like a “ruf=” record and if so add one, pointing to a different address from the “rua=” record.
  5. Add DMARC filtering on your incoming email infrastructure, and re-check all the aggregate and forensic reports.
  6. Fix some more of your email infrastructure, because the DMARC filtering on incoming is likely to show you more forgotten areas as important emails are likely to be between third party senders your employees use and your employees organizational mail system.
  7. Whitelist in your DMARC filter some well known forwarders (mainly some third party senders you are using).
  8. Whitelist in your DMARC filter all the mailing lists your employees are using
  9. Do you have a phishing problem? If not then you may have fixed enough your infrastructure. The next steps are harder to put in place and only warranted if the the benefits of fighting phishing outweighs the complexity that will arise from a very restricted infrastructure.
  10. Be mindful there are at least two cases where DMARC is likely to reject emails:
  11. Email forwarding
  12. Mailing lists
  13. Consider moving transactional mail to a separate domain from employee mail, which you can do more aggressive enforcement on.
  14. Get your employees to use a personal email address to subscribe to mailing lists (until more mailing lists work with DMARC).
  15. Get all third party providers to be DMARC compliant (see this FAQ)
  16. You are ready to move to p=quarantine and/or p=reject
  17. Congratulations!

Now work on all the cases DMARC does not cover: cousin domains, friendly display, receivers with no DMARC filtering, et cetera

How can I put DMARC records on many domains at once?

Some organizations may have registered many domain names for brand protection or other reasons. Managing all these domains is often challenging. Here is one possible way to put a DMARC record on all of them and easily control changes. You can use CNAME for the DMARC record and wildcard for the reporting.

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com" _dmarc.example.net. IN CNAME _dmarc.example.com.

*._report._dmarc.example.com IN TXT "v=DMARC1"

Now there is only one DMARC record to manage. The report record is needed because you are asking for the aggregate report for example.net to be sent to another domain, example.com. Therefore this domain must indicate it is willing to receive such reports. With a wildcard, this domain indicates it is willing to receive reports about any domain. Set email filtering correctly for the mailbox dmarc-rua@example.com to avoid receiving reports you are not interested in.

As a marketing firm, how can I send DMARC-compliant mail for my customers?

There are many answers to this question, depending on the relationship you have with your customers and the method by which you send mail for them.If you send as your own brand on their behalf (e.g. from customerbrand@marketingbrand.com), then you should be able to authenticate your own mail with SPF, DKIM, and DMARC.If, however, you send mail as their brand (e.g. from marketingname@customerbrand.com), you will need to work closely with your customer to ensure you send authenticated mail. This will require that you work with your customer so that at least one of SPF and/or DKIM passes, preferably both. For SPF, this will require that they edit their SPF record to include the IP addresses of your sending servers. For DKIM, you can either arrange for them to provide you with a key that will allow you to sign the email with their domain, or you can generate the signing key while providing the public key for the customer to publish. Otherwise you will have to relay the email through their infrastructure so they can sign it.

You can read the same question, but from the customer point of view: My organization uses third-parties senders, how can I get them DMARC compliant?

Overall, asking your customer to whitelist your sending IPs will work if and only if your email’s destination is your customer domain exclusively. This means that your email is not expected to transit through a discussion list or be otherwise forwarded in a way that breaks DMARC alignment validation.

You should test extensively, sending to many different mailboxes before enabling any service for production use. An excellent first step is to ask your customer to publish a DMARC “p=none” record for a couple of months so that you and the customer can gather data to help inform your decision.

Once you have learned how to do this, be sure to train your sales representatives in how to handle requests from customers who want DMARC compliance.

My mail is going to the spam folder now, is DMARC the problem?

In general, DMARC does not address inbox placement. If you’ve correctly implemented DMARC, it won’t change whether or not your mail is considered spam. You can, however, incorrectly configure your mail flow so that DMARC fails, potentially increasing the likelihood of your mail being seen as spam. For this reason, it is highly recommended that you start with a DMARC “p=none” record in order to monitor the results before moving on to a quarantine or reject policy. In short, DMARC is not an email filter, it is a policy tool which applies to unauthenticated emails. The goal of DMARC, when your policy is “p=reject”, is to get the receiver to reject emails that don’t come from your email infrastructure, not to help them make a decision about whether the email you did send is spam.

However, if your policy is “p=quarantine” and you have configuration issues, your mail will be placed in the spam folder because that is what you are asking for.

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

Technically savvy people can check the email headers and look for the Authentication-Results header. It may look like:

Authentication-Results: mail.example.com; spf=pass smtp.mailfrom=member@example.com; dkim=pass header.d=example.com; dmarc=pass d=example.com

This header indicates that the server mail.example.com performed SPF, DKIM and DMARC tests. SPF and DKIM tests passed and that the DMARC test passed.

What changes in the draft submitted to the IETF affect me as a sender?

The section(s) where a given change was made are noted with {X.Y} at the end of each bullet below. To see a side-by-side comparison between the original version published on in March, 2012 and the version submitted to the IETF in March 2013, use this link. NOTE: The version at the IETF was subsequently updated on December 6, 2013. It is recommended that you ensure compliance with the most recent version available from the specification page.

I have domains that do not send emails, how can I protect them?

The following examples will attempt to provide example of the records needed, using BIND’s record notation. Please translate to your nameserver’s required format as needed.

First create a DMARC record on your main domain (example.com) for all your parked domains:

_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com;"

If example.net is a parked domain you can then protect it this way:

_dmarc.example.net IN CNAME _dmarc.parked.example.com example.net IN TXT "v=spf1 -all" *.example.net IN TXT "v=spf1 -all"

The CNAME allows you to control in one place all your parked domains. If you want, for instance, to start receiving failure reports for all your parked domains, you just need to update one DNS record. In the example above the record becomes:

_dmarc.parked.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:aggregates@example.com; ruf=mailto:failures@example.com;"

This will update all the domains using this CNAME. The wildcard on the TXT record for SPF will protect any subdomain or host under this domain.

To be able to receive reports for example.net at the mailboxes at example.com you must create a Report Authorization Record:

example.net._report._dmarc.example.com IN TXT "v=DMARC1;"

If you have many parked domains you can consider using a wildcard, instead of creating a record for each domain you are protecting:

*._report._dmarc.example.com IN TXT "v=DMARC1;"

However, you can then receive reports for any domains, ensure you are protected against false reporting and the potential load on your infrastructure.

Finally, please realize that this protection is only good with receivers that support DMARC.

Why are messages I send on behalf of visitors to my website being blocked?

This depends on how you are sending these messages. If you are simply taking the website visitor’s email address and inserting it into the “From:” header of the message, and sending that message from your own servers, then you are impersonating the domain in their email address – in a way that is indistinguishable from spammers. These practices may have worked previously – in many cases for decades – because before spam became a literally overwhelming problem, nobody checked. The most successful initial mechanisms to combat such spam were IP address-based blocklists, and so your site may have been allowed to continue because it did not appear on such a list.

For the past decade, however email authentication has been introduced as a filtering mechanism, and is increasingly being used to detect and block such messages.As a best practice, you should instead be using a domain you control in the address of the From: header, and use mechanisms like SPF, DKIM, and DMARC to show that this message is authorized to use your domain. In the example below, the site visitor’s name is shown in the descriptive part of the From: header, and the Reply-To: header is set to the website visitor’s address, but the actual address used in the From: header clearly indicates that your website is the origin of the message.

From: "John Doe via the Example Website" service@website.example.com Reply-To: "John Doe" john@firstmailboxprovider.com To: "Bob Smith" bob@secondmailboxprovider.com Subject: "An article I thought you would find interesting"