Follow ZDNET: Add us as a favorite source On Google.
ZDNET Key Takeaways
- There are three DNS records that protect your domain and protect your email from junk.
- Running all three gives you complete coverage.
- They also protect your domain from being hijacked.
If you send a lot of work emails and keep getting radio silence, it’s very possible that your emails are ending up in someone’s spam folder.
There are a few reasons why this happens that don’t always have to do with the content of your email. Typically, your domain may not be authenticated, which gives receiving mail servers all the reason they need to silently file your messages into spam folders.
Too: How a burner email can protect your inbox – setting up an email is easy and free
I’ve seen this bother people more often than you’d expect, including teams with really good email content. Thankfully, there is an easy solution involving three DNS records called SPF, DKIM, and DMARC. Together, they prove to the Internet that your emails are legitimate. They also protect your domain from being hijacked by cyber criminals so they can impersonate you in emails.
Gmail and Yahoo began implementing these authentication requirements for bulk senders in February 2024. Subsequently, Microsoft added similar requirements for Outlook.com, Hotmail, and Live.com in May 2025. If you haven’t set these up yet, they are no longer optional.
What SPF, DKIM and DMARC actually do
Each of the three protocols addresses a different weak point in email authentication. SPF verifies that the server sending your email is authorized to do so. DKIM adds a cryptographic signature to your outgoing messages, verifying that they have not been altered in transit.
DMARC ties the two together by publishing a policy that tells the receiving server what to do if the check fails, and sends the authentication report back to you.
You really need all three. SPF alone can’t prevent someone from manipulating the “from” address that your recipients see in their inbox. DKIM alone will not catch email sent from an unauthorized server. Only when you run all three do you get full coverage against both deliverability issues and domain spoofing.
1. SPF: Authorize the server sending on your behalf
SPF (Sender Policy Framework) is a DNS TXT record that lists every IP address and mail server authorized to send email on behalf of your domain. When a recipient’s mail server receives a message claiming to be from you, it checks that record against the sending server’s IP. If the IP is not in the list, the message fails.
Too: Here’s my favorite email trick to automatically clear inbox clutter
Setting this up means logging into your domain registrar (GoDaddy, Cloudflare, Namecheap, etc.) and adding a TXT record to the root of your domain. Here’s how it works:
-
First get your SPF value from your email service. Google Workspace, Microsoft 365, and most platforms provide the exact record values ​​that you need to copy-paste onto their domain authentication page. For Google Workspace, this is: v=spf1 include:_spf.google.com ~all.
-
If you send emails through multiple services, you should put them in a single record, for example v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all.
-
Log in to the platform where you manage your domain’s DNS records. It could be GoDaddy, Cloudflare, Namecheap, Route 53 etc. Create a new TXT record on your DNS page, set host to @ (your root domain), and paste the SPF value from the previous step.
It’s that simple! Note that your domain can only have one SPF TXT record, which will have no more than 10 DNS lookups. Creating a second SPF record instead of editing the first will break both. So keep your list of authorized senders short.
2. DKIM: Add a tamper-proof signature to every email
DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign your outgoing messages. Your mail server attaches a signature using the private key it holds, so recipients can verify it against the matching public key published in your DNS. The signature check fails if the email was modified at any point between your server and the recipient’s inbox.
Too: This Simple Email Trick Saves Me from Annoying Marketing Spam (And It’s Free)
Google Workspace, Microsoft 365, and most major email platforms like SendGrid will generate a DKIM key pair for you. Your job is to copy the public key they provided and paste it into your domain’s DNS settings as a new TXT record.
Although the exact setup steps depend on your email provider and domain registrar, here’s a general overview of what you need to do.
-
Google Workspace, Microsoft 365, SendGrid, Mailchimp, and other email service providers will create a DKIM record for you if you navigate to their domain authentication settings page. For example, if you use Google Workspace, it’s located in the Google Admin console under Apps > Google Workspace > Gmail. Click to create a new record and copy these values ​​first.
-
Next, go to your domain registrar’s DNS settings page and create a new TXT record as you did when setting up the SPIF earlier. Note that some providers may also require you to add this as a CNAME record instead of a TXT record, so check your email provider’s documentation.
-
Paste the host name and record value you received from your email provider into the new DNS record. Make sure there are no typing errors as this may affect domain security.
-
Now, return to your email provider’s authentication settings. This is where you enable DKIM signing for your domain. In Google Workspace, this is done by revisiting the “Authenticated Email” page in the Admin Console and clicking “Start Authentication.” Remember that you should do this after 24-48 hours as it takes some time for the DNS records to propagate to your domain.
DKIM is particularly useful for forwarded messages. Forwarding often breaks SPF as the IP address changes, but the DKIM signature generally remains intact. This means that a forwarded email can pass authentication even if SPF alone has failed.
3. DMARC: Set rules for what happens when authentication fails
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that enables SPF and DKIM to be implemented. Without this, a receiving server that detects a failed probe has no instructions about what to do next, and you have no idea what is failing or why. Here’s how to get it up and running:
-
Start by creating a dedicated inbox for DMARC reports, like awards@yourdomain.com.
-
Most email providers offer a DMARC generator in their dashboard, but you can also use a third-party service like MXToolbox or DMARCLY.
-
Add a new TXT record. The host name should read _dmarc. Paste the record value directly from your DMARC generator.
-
Keep track of any failure reports for 2-4 weeks in your dedicated inbox. This will reveal any issues with the mailbox that need to be addressed for better delivery.
Too: I tested NordVPN’s free scam checker with real phishing emails – here’s how it performed
Like the other two, DMARC is a TXT record, this time appended to _dmarc.yourdomain.com. A simple initialization record looks like this: v=DMARC1; P=none; rua=mailto:reports@yourdomain.com. The P=None setting means that receiving servers will take no action on failed messages, but will send you aggregate reports at the address you specify. Those reports show what services are sending on your behalf and whether they pass authentication.
Once you’ve reviewed a few weeks of reports and confirmed that your legitimate mail is passing through cleanly, you can tighten the policy. Move to p=Quarantine to send failed messages to spam, then finally move to p=Reject to block them completely.
Going straight to p=reject before reviewing your report is probably the most common implementation mistake I see, and it blocks your own marketing or transactional emails.
Why can’t you choose just one?
Every protocol has a gap that others fill. SPF checks the sending server, but not the “from” address that recipients actually see, so an attacker can pass SPF even while impersonating your domain. DKIM verifies the integrity of the message but does not check whether the signing domain matches the visible sender.
DMARC enforces alignment between all these elements and applies your chosen policy when something is out of alignment.
The benefits of combined delivery capacity are measurable. According to Validity’s 2025 Email Benchmark Report, properly certified domains see inbox placement rates nearly 60 percentage points higher than uncertified ones. For anyone running a cold outreach campaign or bulk newsletter, this difference is the difference between a campaign that drives results and one that disappears entirely.
How to verify that your records are working
DNS changes typically take 15 minutes to 48 hours to propagate worldwide. Once that window passes, free tools can quickly tell you if everything is configured correctly. MX Toolbox has separate checkers for SPF, DKIM, and DMARC. You can also send a test email to check@dmarcly.com, which replies with a full authentication report for your domain.
Too: Best Email Hosting Services 2026: Expert Tested and Reviewed
Your DMARC Aggregate reports are the most valuable ongoing signals. Within a day or two after your DMARC record is published, reports will start arriving at the address you specified. They show every server sending email under your domain and whether each server is passing or failing authentication. Reading these regularly is the best way to catch misconfigurations early, before they impact your deliverability or allow your domain to be abused in phishing campaigns.
