About DMARC

Background #

Email spammers can forge the “From” address on email messages to make it appear that messages are coming from your domain. This is a potential liability for many reasons.

Domain providers should support Domain-based Message Authentication, Reporting, and Conformance (DMARC) as a way to prevent this type of spam. Use DMARC to define how your mail provider handles messages that appear to be sent from your domain but that are actually fraudulent.

*NOTE TO GMAIL USERS - Gmail does the DMARC check by default.

Before you start #

Set up Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) before you set up DMARC:

DMARC uses SPF and DKIM to verify that messages are authentic. Messages that do not pass SPF or DKIM trigger your DMARC policy.

How DMARC works #

DMARC helps email senders and receivers verify incoming messages by authenticating the sender’s domain. DMARC also defines the action to take on suspicious incoming messages.

DMARC checks messages #

To pass the DMARC check:

• Incoming messages must be authenticated by SPF, DKIM, or both.
• The authenticated domain must align with the domain in the message From: header address.

DMARC actions for failed messages #

When an incoming message doesn’t pass the DMARC check, the DMARC policy defines what happens to the message. There are three possible actions:

• Take no action on the message.
• Mark the message as spam and deliver to the recipient’s spam folder.
• Tell receiving servers to reject the message.

DMARC reports #

You can set up DMARC to send you a daily report from all participating email providers. The report shows: 

• How often messages are authenticated
• How often invalid messages are seen
• DMARC policy actions that occur

Based on what you learn from the daily reports, you can refine your DMARC policy. For example, you can change your policy from none (monitor only) to quarantine to reject after you see that valid messages are being authenticated.

DMARC and third-party email providers #

For DMARC to effectively manage suspicious messages, messages should be sent from your own domain. Messages sent from third-party email providers for your organization can appear invalid and be rejected, depending on the DMARC policy.

To prevent messages from third-party email providers from being marked invalid:

• Share your DKIM key with the mail provider so they can add the key to outgoing messages.
• Ask the mail provider to send messages through your network.

Add a TXT record to turn on DMARC #

To turn on DMARC, update your domain settings with a DNS TXT record.

Follow these steps to add a DMARC TXT record for your domain.

Important:

• The domain used in these examples is an example domain. Replace test.com with your own domain. 
• Replace the example values with values for your domain’s DMARC policy.

1. Sign in to the management console for your domain provider.
2. Locate the page where you update DNS records. Subdomains: If your domain host doesn’t support updating subdomain DNS records, add the record to the parent domain. Learn how to update DNS records for a subdomain.
3. Add a DNS record at _dmarc
   
   TXT record name: In the first field, under DNS Hostname, enter:
   _dmarc.test.com
   
   TXT record value: In the second field, enter the values that define your DMARC policy, for example:
   v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@test.com; pct=90; sp=none
4. Save your changes.

DMARC TXT record values #

Note: Gmail does not support the DMARC ruf tag, used to send failure (forensic) reports.

Tag Name Required Description and values

v - Required

Protocol version. Must be DMARC1.

p - Required

Defines how your domain handles suspicious messages:

• none: Take no action on the message. Log suspicious messages in the daily report.
• quarantine: Mark the messages as spam and move to the recipient's Gmail spam folder.
• reject: Tell receiving servers to reject the message. When this happens, the receiving server should send a bounce to the sending server.

pct - Optional

Sets the percent of suspicious messages that the DMARC policy applies to. Suspicious messages are messages that fail the DMARC check.

Must be a whole number between 1 and 100. The default is 100.

rua - Optional

Email address to receive reports about DMARC activity for your domain. Use your own email address or create a new email address to receive reports.

The email address must include mailto:, for example: mailto:dmarc-reports@test.com

To send the report to more than one email address, separate emails with a comma.

sp - Optional

Sets the policy for messages from subdomains of your main domain. Use this option if you want to use a different DMARC policy for your subdomains.

• none: Take no action on the message. Log suspicious messages in the daily report.
• quarantine: Mark the messages as spam and hold it for more processing.
• reject: Instruct receiving servers to reject the message.

adkim - Optional

Sets the Alignment mode for DKIM, which defines how exactly message information must match DKIM signatures.

• s: Strict. The sender domain name must exactly match the corresponding d=name in the DKIM mail headers.
• r: Relaxed (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted.

aspf - Optional

Sets the Alignment mode for SPF (ASPF), which defines how exactly message information must match SPF signatures.

• s: Strict. The message from: header must exactly match the domain.name in the SMTP MAIL FROM command
• r: Relaxed (default). Allows partial matches. Any valid subdomain of domain.name is accepted.

Deploy DMARC slowly #

Use the policy (p) option. Set and change the policy option using the p tag value in the TXT record. Start with a quarantine policy so you can inspect suspicious messages. Then gradually modify the policy based on what you learn from quarantined messages and daily reports.

1. p=none: Monitor email traffic and look for issues in the daily reports, but let all message through. Watch for spoofed messages and messages not signed with DKIM or SPF.
2. p=quarantine: When you’re familiar with email patterns you see in the daily reports, change the policy to quarantine. Continue to review the daily reports and view the messages that are being set aside (quarantined) as spam.
3. p=reject: When you’re sure all messages from your domain are signed, change the policy reject to start filtering spam messages. Continue to review daily reports to check that you’re filtering out spam and sending valid email to recipients.

Use the percent (pct) option. The percent option specifies what percentage of suspicious messages have the DMARC policy applied. Suspicious messages are messages that fail the DMARC check. The default is 100% (all suspicious messages). Set the percent option to fewer messages at first, increasing the percentage every few days as you refine your DMARC policy. For example, set the percent option to 20 to filter 20% of rejected or quarantined messages to start with. The following week, change the value from 20 to 50 to filter 50% of the messages.

Example deployment: Here is an example of how to use the p and pct options to gradually deploy a DMARC policy. Update your DMARC policy over time with these values:

1. p=none pct=100
2. p=quarantine pct=1
3. p=quarantine pct=5
4. p=quarantine pct=10
5. p=quarantine pct=25
6. p=quarantine pct=50
7. p=quarantine pct=100
8. p=reject pct=1
9. p=reject pct=5
10. p=reject pct=10
11. p=reject pct=25
12. p=reject pct=50
13. p=reject pct=100

Daily DMARC reports #

DMARC daily reports are in XML format and have information about email flow. Use the reports to:

• Verify outbound email sources are authenticated
• Verify the email servers sending messages from your domain are legitimate
• Respond if a new server is online, or an existing server has configuration issues