Email remains the single largest attack vector, and domain spoofing continues to power phishing, BEC (Business Email Compromise), and impersonation attacks. In 2025, major mailbox providers like Google and Yahoo now require DMARC for bulk senders, making proper deployment more important than ever.
DMARC (Domain-based Message Authentication, Reporting & Conformance) ensures that only authorized sources can send email using your domain. It provides authentication, reporting, and enforcement so mailbox providers can confidently block spoofed messages.
This guide explains DMARC using modern standards, how it works and how to incorporate it into your life.
What is DMARC?
DMARC, which stands for Domain-based Message Authentication, Reporting & Conformance, is an email authentication protocol that builds on SPF and DKIM, adding a critical requirement called identifier alignment.
It allows domain owners to:
Authenticate legitimate email sources
Block unauthorized or spoofed email
Receive reports on how their domain is being used
Improve deliverability and trust
DMARC is published as a TXT record in DNS and uses policies (none, quarantine, reject) to instruct receivers how to treat emails that fail authentication.
Why Is DMARC Important in 2025?
Email spoofing is still trivial
Attackers can send email claiming to be:
Your organization
Your CEO
Your support team
Your brand
and in many cases the message will look legitimate unless authentication is enforced.
Users can’t visually distinguish real vs fake email
Logos, brand colors, and sender names can be faked in seconds.
Mailbox providers now enforce DMARC
As of early 2024:
Google requires DMARC for bulk senders.
Yahoo has similar requirements.
Major providers increasingly penalize non-DMARC domains.
DMARC gives you domain-level control
It allows you to instruct receivers:
“Monitor only”
“Send suspicious messages to spam”
“Reject everything that fails alignment”
This dramatically reduces phishing impact, protects your brand, and improves trust.
How DMARC actually works
DMARC evaluates three things to determine whether an email is legitimate and allowed to use your domain:
The SPF authentication result
The receiving mail server checks whether the email was sent from an IP address that your domain has authorized via its SPF record. DMARC then uses that result, but only considers it valid if the SPF domain aligns with the domain shown in the From: header.
The DKIM authentication result
The server verifies the DKIM signature using the public key published in your DNS. If the signature is valid, the message is authenticated. DMARC then checks whether the DKIM signing domain (the d= value) matches or aligns with the domain in the From: header.
Identifier alignment
Alignment is the core of DMARC. Even if SPF or DKIM technically “passes,” DMARC will ignore the result unless the authenticated domain matches (strict alignment) or shares the same organizational domain (relaxed alignment) as the domain in the visible From: address.
This prevents attackers from passing SPF or DKIM using their own domains while spoofing your brand in the From: field.
How DMARC decides pass or fail
DMARC will pass an email if either of the following conditions is met:
SPF passes AND the SPF domain aligns,
OR
DKIM passes AND the DKIM domain aligns
The key is that only one needs to pass and align, not both.
If neither SPF nor DKIM both pass and align, then DMARC fails, and the receiving server applies the DMARC policy you’ve published (none, quarantine, or reject).
Why this matters
This design gives domain owners flexibility so that:
DKIM can pass even when SPF breaks due to forwarding
SPF can pass even if a service doesn’t support DKIM
Alignment ensures that authentication can’t be spoofed by third-party domains
DMARC protects the human-visible “From:” address more strongly than SPF or DKIM alone
Understanding SPF
SPF stands for Sender Policy Framework. An SPF record tells which email servers are authentic and permitted to send emails on behalf of a specific domain.
SPF works by defining authorized sending IP addresses and mechanisms in a DNS TXT record. Receiving mail servers check this record to verify whether the sending server is allowed to send mail for the domain.
SPF limitations you must know
SPF breaks on forwarding because the IP changes.
SPF has a 10-lookup limit. Exceeding it causes permanent SPF failures.
The “all” mechanism matters:
-all: hard fail (recommended when fully configured)~all: soft fail (used during rollout)?all: neutral (rarely used)
Steps for creating a good SPF Record
Login to the domain’s DNS host.
Choose to edit the primary zone for the Top-Level-Domain
Create a new DNS TXT record for SPF using the following conventions
Here are some credible SPF records you can copy and paste into a new TXT record.
Google workspace:
v=spf1 include:_spf.google.com -all
Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all
Zoho:
v=spf1 include:zoho.in ~all
Best SPF best practices
Use CIDR blocks to summarize IP ranges.
Here’s an example of IP address ranges that can be specified with CIDR
v**=**spf1 a mx ip4:192.168.0.0/24 ip4:192.168.1.0/24 -all
This means:
ip4:192.168.0.0/24 **=** 256 IP addresses; range: 192.168.0.0 – 192.168.0.255
ip4:192.168.1.0/24 **=** 256 IP addresses; range: 192.168.1.0 – 192.168.1.255
Use _spf.example.com subdomains
Considering a larger organization, the best way to reduce the number of characters in an SPF record is to create an SPF specific subdomain represented as: _spf.example.com. Using “_spf” as the subdomain instructs a mail server to treat the subdomain as a storage container, which is only used for listing additional SPF information.
Google is a huge organization and has a lot of IP addresses represented in different netblocks due to the size and scope of the organization. Placing all this information into one SPF record would easily exceed the DNS character boundaries.
They resolved it by creating smaller storage containers of SPF records with IP addresses that are shorter and combined them together using include statements.
Here’s a list of netblocks that Google uses and the corresponding SPF records:
_netblocks.google.com v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all
_netblocks2.google.com v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all
_netblocks3.google.com v=spf1 ip4:172.217.0.0/19 ~all
In order to keep the SPF record short, they created an SPF specific subdomain of _spf.google.com and references each netblock using an include statement. The include statement tells a mail provider to search for additional SPF information for the domain listed.
_spf.google.comv=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all
Then it’s added to their SPF specific subdomain _spf.google.com with an include statement to the google.com SPF record.
And the final outcome is a simple SPF record for google.com that’s simple and short.
google.comv=spf1 include:_spf.google.com ~all
Before you create SPF specific subdomains, though, let’s try to use better CIDR notation for IP ranges in order to reduce the length of our SPF records. That’s the more straightforward way.
Avoid +all
These are dangerous because they effectively allow anyone in.
Understanding DKIM
DKIM stands for DomainKeys Identified Mail. It is also set up as a new TXT record in the domain’s DNS. Basically it is an encryption tool that allows senders to digitally sign email to help keep them private.
DKIM uses cryptographic signatures to verify:
The email content hasn’t been altered
The sending service is authorized
Why DKIM matters
DKIM survives forwarding unlike SPF
DKIM supports alignment, a key requirement for DMARC
Providers now recommend 2048-bit keys for security
Correct DKIM setup
You publish a TXT record at:
selector._domainkey.example.com
Your mail provider generates:
The private key (kept by them)
The public key (published in DNS)
DKIM example (google workspace)
Depending on the mail service provider you’re using, there are specific unique steps for each of them.Let’s look at the example of setting up DKIM using Google Workspace.
Open Google Admin Console
Go to Apps → Google Workspace → Gmail → Authenticate Email
Generate a 2048-bit DKIM key
Publish the TXT record in DNS
Enable DKIM signing
Setting up a DMARC record
Alright now we have completed setting up SPF and DKIM records. Now we can move on to setting up the DMARC records.
Create a DMARC configuration
A simple, generic DMARC record to start with will look like this
v=DMARC1; p=none; rua=mailto:admin@example.com
Required tags
v: It stands for version and is always set to DMARC1 as this is the current version of DMARC in use.
p: It stands for **policy which decides how to handle failed mail.
Common optional tags
rua=mailto: where aggregate reports go
ruf=mailto: forensic reports (limited support in 2025)
pct= percentage of traffic to enforce
aspf= SPF alignment mode (strict/relaxed)
adkim= DKIM alignment mode
The correct 3-phase DMARC rollout strategy
We can follow a 3-phased approach to fine tune the DMARC email security configuration. Here we include some example DMARC TXT records using the common tags that we can modify as our process progresses. We start with an initial DMARC configuration that uses the policy setting as “none”, then moving to a restrictive policy setting of ‘quarantine’, and then onto the goal of a policy set to ‘reject’ all illegitimate messages.
Phase 1: monitor (p=none)
Goal: Observe traffic without affecting delivery.
During the initial phase of introducing DMARC email security to our DNS record we don’t implement any actions. It’s for just testing the DMARC and we do not intend to interrupt the flow of legitimate mail flow.
With that in mind, we can start with a policy that is least restrictive, meaning it won’t interfere with normal mail delivery.
This is a good choice for the first two or three weeks and it ensures that the legitimate emails are flowing and being delivered as it should be. This record will take no action on messages that appear to be from our example.com but don’t pass DMARC email security checks.
v=DMARC1; p=none; rua=mailto:admin@example.com
Phase 2: quarantine (p=quarantine)
Goal: Move suspicious mail to spam.
Through the second phase we’ll change the policy tag value to “quarantine” to send illegitimate messages to spam/junk folders, though making our policy to be somewhat restrictive in action. In order to make our policy restrictive in nature, we need to change the p tag’s value to “quarantine”.
Along with the new value we also introduce the pct tag, which stands for percentage, that allows us to set a value that tells DMARC to sample that much of the total flagged traffic (messages that fail SPF and/or DKIM checks) for analysis. Typically, a good value for pct is 1, initially.
Start enforcement gradually using pct=1:
v=DMARC1; p=quarantine; pct=1; rua=mailto:admin@example.com
Increase pct to 25, 50, 75 and finally 100.
Phase 3: full enforcement (p=reject)
Goal: Block spoofed email entirely.
In the final phase we’ll change the policy tag value to “reject” to block illegitimate messages.
Start with:
v=DMARC1; p=reject; pct=1; rua=mailto:admin@example.com
We’ll start by setting the pct tag at 1 and gradually increase it as we go. Once we’re 100% certain, we’ll then use this type of record and reject 100% of the messages that don’t pass DMARC checks.
v=DMARC1; p=reject; rua=mailto:admin@example.com
This is the gold standard.
How to add a DMARC record to DNS
In your DNS management console, Create a new TXT record:
Name: _dmarc
Value: DARC record which created
Save changes and allow it to propagate.
Final thoughts
DMARC is no longer optional, it is now a foundational requirement for email security and brand protection. When implemented correctly, DMARC:
Prevents domain spoofing
Reduces phishing & BEC attacks
Improves email deliverability
Strengthens compliance posture
Enables BIMI (brand logos in inboxes)
By following the above mentioned steps you’ll be able to configure DMARC for your domain and thereby make sure email security is addressed correctly.
