DMARC¶
What's DMARC you ask? Well, here's the 101:
What is DMARC?¶
DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is a way to protect your email domain from being misused by imposters. Let's imagine three people: Alice, Bob, and Mallory.
Alice is the owner of a trusted email domain. Bob is a friend who receives emails from Alice. Mallory is a malicious person who tries to send fake invoices to everyone pretending to be Alice.
Without DMARC, Mallory could easily send an email to Bob, pretending to be Alice, and Bob might believe it came from Alice because it looks legitimate. That might be in the form of spoofing, phishing or some other malicious action.
With DMARC, Alice publishes a special policy for her email domain that tells email servers like Bob's how to handle messages that claim to be from her domain name. This policy includes instructions to check if the email really comes from her domain and if it passes certain authentication checks.
When Mallory tries to send a fake email to Bob, DMARC helps Bob's email server recognize that the email didn't come from Alice's trusted sources. Depending on Alice's policy, Bob's email server can either reject the fake email, put it in quarantine, or allow it through but report the incident to Alice.
In summary, DMARC helps ensure that emails truly from Alice are trusted by Bob while blocking or flagging attempts from Mallory to impersonate Alice. This way, DMARC helps maintain the integrity and security of email communications.
DMARC Implementation Instructions¶
Start small with DMARC¶
Follow these four steps to implement an increasingly aggressive policy. Reports are sent by default every 24 hours.
Step 1: Start with a Monitoring Policy¶
Baby steps: Reporting only. Begin by gathering data on email sources sending on behalf of your domain.
- Set up a DMARC record with a policy of
none, without impacting delivery. - Publish your DMARC record in your DNS — you'll create a TXT record with the name _dmarc & the following data: "v=DMARC1; p=none; rua=youremail@example.com; ruf=yourtechemail@example.com; pct=100; fo=1;aspf=s;adkim=s"
- Analyze DMARC reports sent to the specified email addresses (rua and ruf) to identify legitimate and illegitimate email sources.
- Once you've confirmed the systems sending email as your domain are compliant, transition to quarantine.
Step 2: Transition to quarantine.¶
Objective: Start to quarantine suspicious emails to reduce potential abuse while still monitoring email traffic. Reduce pct, and swap p=none for p=quarantine.
- Update your DMARC record to a quarantine policy: "v=DMARC1; p=quarantine; pct=50; rua=mailto@example.com; ruf=yourtechcontactexample.com; fo=1;aspf=s;adkim=s"
- Day by day, amp the record up: "v=DMARC1; p=quarantine; pct=75; rua=mailtoexample.com; ruf=yourtechcontactexample.com; fo=1;aspf=s;adkim=s"
- "v=DMARC1; p=quarantine; pct=100; rua=mailto@example.com; ruf=yourtechcontactexample.com fo=1;aspf=s;adkim=s"
- Monitor the impact of each increase and ensure legitimate email delivery is not affected.
- Update SPF and DKIM records as necessary to align with legitimate email sources.
Step 4: Implement a Reject Policy¶
Objective: Transition to a reject policy to block all unauthenticated email, ensuring maximum protection.
- Update your DMARC record to a reject policy: "v=DMARC1; p=reject; pct=100; rua=mailto@example.com; ruf=yourtechcontactexample.com; fo=1;aspf=s;adkim=s"
- Monitor the impact to ensure that legitimate email delivery is not affected and that only unauthenticated emails are being rejected.
- Continue to analyze DMARC reports and adjust your SPF and DKIM records to include any new legitimate email sources.
Final Considerations¶
- Regularly review and update your DMARC, SPF, and DKIM records & notices to adapt to changes in your email sending infrastructure.
- Ensure all legitimate email sources are properly authenticated through SPF and DKIM to prevent legitimate emails from being rejected or quarantined.
DMARC RECORD BUILDER¶
Domain¶
The domain is the part of your email address that comes after the '@' symbol. For example, in "alice@example.com", "example.com" is the domain. This is where you specify the domain for which you want to create the DMARC record.
Policy¶
The policy defines how you want receiving email servers to handle messages that fail DMARC authentication checks. There are three options: - none: Take no specific action, just monitor. - quarantine: Treat the email as suspicious and put it in the spam/junk folder. - reject: Reject the email outright, so it never reaches the recipient
Subdomain Policy¶
The subdomain policy (sp) applies the same DMARC policy to all subdomains of the specified domain. This ensures that the same rules are enforced for emails coming from subdomains as well. For example: subdomain.example.com
ASPF¶
SPF (Sender Policy Framework) alignment specifies how strictly the SPF check is applied.
- r (relaxed): The domain in the "Return-Path" address just needs to be a subdomain of the "From" address.
- s (strict): The domain in the "Return-Path" address must exactly match the domain in the "From" address.
ADKIM¶
DKIM (DomainKeys Identified Mail) alignment specifies how strictly the DKIM check is applied.
- r (relaxed): The domain in the "d=" tag of the DKIM signature just needs to be a subdomain of the "From" address.
- s (strict): The domain in the "d=" tag of the DKIM signature must exactly match the domain in the "From" address.
RUA¶
The aggregate report (rua) is an email address to which reports about DMARC failures and statistics are sent. These reports help you monitor and understand the authentication results for your domain.
RUF¶
The forensic report (ruf) is an email address to which detailed information about individual DMARC failures is sent. These reports provide specific details about Where does one each failed email, which can be useful for debugging and investigating incidents.
PCT¶
The percentage (pct) specifies what percentage of emails should be subjected to the DMARC policy. This can be useful if you want to gradually implement DMARC enforcement. For example, setting it to "50" means that only 50% of emails failing DMARC checks will be affected by the policy.
FO¶
The fo tag in a DMARC record specifies the conditions under which failure reports are generated. These reports provide detailed information about email authentication failures, helping you identify and address issues with your email authentication setup. The possible values for the fo tag are:
0: Generate a report if both SPF and DKIM fail to produce a "pass" result. (Default)1: Generate a report if either SPF or DKIM (or both) fails to produce a "pass" result. Recommended.d: Generate a report if the DKIM signature fails to produce a "pass" result.s: Generate a report if SPF fails to produce a "pass" result.