Tutorial: Recommended DMARC rollout

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is designed to be rolled out gradually. Start with a none policy that only monitors email flow, and then eventually change to a policy that rejects all unauthenticated messages.

A none policy lets you start getting reports without the risk of your messages being rejected or sent to spam by receiving servers. You can also set your DMARC policy to apply only to a percentage of the messages sent from your organization. These two features let you deploy DMARC gradually, while remaining in control of your mail flow.

Important: Configure DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) before configuring DMARC. DKIM and SPF should be authenticating messages for at least 48 hours before turning on DMARC. For detailed steps to set up SPF and DKIM, go to Help prevent spoofing, phishing, and spam.

1. Start with a relaxed DMARC policy

Start with a DMARC record with enforcement set to none, and an email address configured to get daily DMARC reports. This lets you start getting reports without risking messages from your domain being rejected or marked as spam by receiving servers. We recommend using this record for at least one week. One week is usually long enough for the daily reports to contain data that is representative of all your mail streams.

Review your daily DMARC reports to verify that messages from your domain are sent by known authorized servers, and pass authentication checks.

We recommend you start with a DMARC policy isn’t too restrictive or that applies to only a small percentage of your mail traffic, for example:

1. Sign in to your domain host to update the DMARC DNS TXT record at your domain provider.
2. Enter a policy that applies to 100% of messages but has enforcement set to none:

   v=DMARC1; p=none; rua=mailto:[e-mail]

The policy is applied to 100% of all messages received by mail servers. However enforcement is set to none, so messages are delivered normally, even when they don’t pass DMARC authentication. Every mail server that gets mail from your domain sends daily reports to [e-mail].

2. Review DMARC reports

Each day, review the reports you receive to find out:

• What servers or third-party senders are sending mail for your domain
• What percent of messages from your domain pass DMARC
• Which servers or services are sending messages that fail DMARC 

Look for any problem trends such as:

• If recipients get valid messages from you, but they’re in the spam folder.
• If you’re getting bounce or error messages from recipients.

To fix problems with messages from your domain being rejected or sent to spam, go to Troubleshoot DMARC issues.

Continue to get daily reports by verifying the updated record still includes the rua tag with your email or mailbox address. We recommend you stay in this phase for at least 7 days before moving to the next phase. The duration of this phase will vary, depending on your organization size and mail flow. 

Learn more about Reading your DMARC reports. 

3. Quarantine a small percentage of messages

After monitoring DMARC reports for at least a week with no adverse results, update your policy to quarantine , and add the pct tag to apply the policy to a small percent of your mail. For example:

1. Sign in to your domain host to update the DMARC DNS TXT record at your domain provider.
2. Add a policy that applies to 5% of messages and has enforcement set to quarantine. Messages in the 5% that don’t pass DMARC are sent to recipients’ spam folder:

   v=DMARC1; p=quarantine; pct=5; rua=mailto:[e-mail]

The policy is applied to only 5% of messages received by mail servers. Messages that don’t pass DMARC are delivered to recipients’ spam folder. Only a small percent of messages are impacted, and recipients can review messages that are sent to spam. Every mail server that gets mail from your domain sends daily reports to [e-mail].

Small organizations might have a good understanding of all mail flows and can apply the policy to a larger percent of messages than large organizations. Large organizations often have multiple mail flows that can include legacy servers and third-party senders.

 We recommend large organizations gradually increase the percent of messages affected, to reduce the risk of many messages being rejected or marked as spam. A small organization might start with quarantining 10% and a very large enterprise might start with 1%.

4: Reject all unauthenticated messages

This is the final step in deploying DMARC. When you’re sure that most or all of the messages sent from your domain are aligned, and passing authentication (SPF and DKIM), you can enforce a stricter DMARC policy.

If DMARC is working as expected, update your policy so the DMARC record policy is set to reject for 100% of messages sent from your organization. For example:

1. Sign in to your domain host to update the DMARC DNS TXT record at your domain provider.
2. Update the record to be more strict. For example:

   v=DMARC1; p=reject; rua=mailto:[e-mail],[e-mail]

The policy affects all messages received by mail servers. If the record doesn’t include the pct tag, the policy applies to 100% of messages sent from your domain. All messages that fail DMARC authentication are rejected. The sender can receive a bounce message for each rejected message. Every mail server that gets mail from your domain sends daily reports to two email addresses: [e-mail] and [e-mail].