A university's admissions team notices that applicants stopped receiving confirmation emails from the website. The mail is being sent; Gmail is rejecting it. In the same month, the IT office gets reports of phishing emails that appear to come from the university's own domain, asking parents to pay a fee. Both problems have the same fix. Three DNS records, SPF, DKIM, and DMARC, tell the world's mail providers which email from your domain is genuine.
What the three records do
| Record | What it says | Analogy |
|---|---|---|
| SPF | Which servers are allowed to send mail for your domain | A guest list |
| DKIM | A cryptographic signature proving the message was not altered and came from an authorized sender | A tamper-proof seal |
| DMARC | What receivers should do when SPF or DKIM fails, and where to send reports | The instructions to the door staff |
DMARC is what stops impersonation. Without it, a criminal can send email that claims to be from your domain, and many receivers will deliver it.
The major mail providers now require them
Since 2024, Google and Yahoo require anyone sending in bulk to their users to authenticate mail with SPF and DKIM, publish a DMARC record, offer one-click unsubscribe on marketing mail, and keep spam complaints low. Microsoft applied similar rules to Outlook.com in 2025. Senders that miss them see mail delayed, sent to spam, or rejected. Even organizations that do not send in bulk benefit: authenticated mail is simply trusted more.
Government agencies have had this requirement longer. Federal agencies were directed in 2017 to deploy DMARC at its strictest setting, and many state and local governments follow the same standard. Impersonating a government agency by email is a common fraud, so a strict DMARC policy protects residents as well as the agency.
Where website email comes from
Websites send more email than people expect: contact form notifications, password resets, event registrations, and newsletters. A WordPress or Drupal site that sends mail directly from its own server will usually fail authentication, because the web server is not on your SPF list and does not sign with DKIM. The fix is to send through an authenticated email service, such as Amazon SES or your organization's email platform, connected through an SMTP plugin on WordPress or a mail module on Drupal.
Check your domain
dig +short TXT example.gov | grep spf dig +short TXT _dmarc.example.gov
You want one SPF record (more than one breaks SPF), and a DMARC record that starts v=DMARC1. If the DMARC record says p=none, it is monitoring only and not yet stopping impersonation.
A safe rollout
- List every service that sends as your domain: your email platform, the website, the newsletter tool, the CRM, the help desk, payroll and HR systems.
- Add each to SPF and turn on DKIM for each service that supports it.
- Publish DMARC at
p=nonewith a reporting address, and read the reports for a few weeks. They show every source sending as your domain, including ones nobody remembered. - Fix the stragglers, then move to
p=quarantineand finallyp=reject, watching the reports at each step. - Protect domains you do not send from with an SPF record allowing nothing and a DMARC reject policy, so they cannot be used for fraud either.
Consider sending newsletters and marketing mail from a subdomain, such as news.example.org, through your email marketing service. Each subdomain builds its own sending reputation, so a campaign that draws complaints does not affect password resets and form notifications from your main domain.
Moving straight to p=reject without the monitoring stage is the most common mistake: it blocks legitimate mail from a forgotten system, often the payroll or ticketing tool.
How eWay can help
Email authentication is set up with DNS records. If eWay manages your DNS, eWay can add them; otherwise they go in with your DNS provider (see managing DNS and pointing your domain to your site). eWay can also configure WordPress and Drupal sites to send through an authenticated mail service, add the required records, and help read DMARC reports during the rollout. Decisions about which third-party services may send as your domain stay with your organization.
What to include in a support ticket
- The domain, and which emails are failing (form notifications, password resets, newsletters)
- A bounce message or the full headers of a message that went to spam
- The services you know send as your domain
eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: privacy on your website and how to write a support request that gets resolved quickly.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article