A customer says they never received your invoice. A prospect asks why your sales email landed in spam. An employee receives a convincing message that appears to come from your domain. These are different problems, but email authentication is part of the answer.
Email authentication gives receiving mail systems evidence that a message claiming to be from your domain was sent by an approved source and was not altered along the way. It does not guarantee inbox placement. It does give Gmail, Outlook, and other receiving systems clear technical signals they can evaluate.
How Email Authentication Works
Your domain name is more than the part of an email address after the @ symbol. It is part of your business identity. When someone receives a message from billing@yourbusiness.com, their mail provider has to decide whether that message is really associated with your business or whether someone is impersonating it.
That decision starts with records published in the Domain Name System, or DNS. DNS is the public directory that tells internet services where to find and how to handle your domain. The three core email authentication standards are SPF, DKIM, and DMARC. They work best together because each checks something different.
Think of them as documented instructions for receiving mail systems. SPF identifies the services allowed to send for your domain. DKIM adds a signed seal to a message. DMARC tells receiving systems what to do when those checks fail and where to send reports.
SPF confirms approved senders
Sender Policy Framework, or SPF, is a DNS record that lists the mail servers and email platforms authorized to send messages using your domain. If you send newsletters through one provider, appointment reminders through another, and employee email through a third, each legitimate sender may need to be included in your SPF record.
The straight answer is that SPF is often incomplete, not absent. A business may set it up for employee mail but forget a website form, invoicing platform, customer relationship system, or marketing tool. Those messages can then fail SPF even though they are legitimate.
SPF also has limits. It checks the technical return path used during delivery, which may not match the address your recipient sees. Message forwarding can also cause SPF to fail because the forwarding server is not on your approved list. That is why SPF alone is not enough.
Your exact fix is to inventory every system that sends mail as your domain, then publish one valid SPF record that includes those authorized services. Do not create multiple SPF records. Receiving systems can treat that as an error. When you add or remove a sending platform, review SPF again.
DKIM signs the message
DomainKeys Identified Mail, or DKIM, adds a digital signature to outgoing email. The sending system applies the signature, and the receiving system retrieves a public key from your DNS to verify it. A valid DKIM signature shows that the message came through a system with access to the matching private key and that signed parts of the message were not changed in transit.
DKIM is especially useful when SPF does not survive forwarding. It also gives you a stronger identity signal because the signature can align with the domain visible in the From address.
Most major email platforms can generate DKIM keys for you, but the setup still needs attention. You may need to publish one or more DNS records using a selector, which is a label that identifies a particular DKIM key. If the selector is entered incorrectly, the record is missing, or the platform has not been told to start signing, DKIM will fail.
After enabling DKIM, send a real test message and verify that the signature passes. A record can exist in DNS while messages remain unsigned, so checking both sides matters.
DMARC sets the policy
Domain-based Message Authentication, Reporting, and Conformance, or DMARC, connects SPF and DKIM to the From address people actually see. It requires alignment, meaning either SPF or DKIM must pass using a domain that matches, or is closely related to, the visible From domain.
DMARC also lets you publish a policy. A monitoring policy asks receiving systems to send reports without requesting action on failures. A quarantine policy asks them to treat failing messages with suspicion. A reject policy asks them not to accept messages that fail DMARC. The right policy depends on whether you have identified every legitimate sender first.
For many businesses, starting in monitoring mode is sensible. The reports can reveal systems you did not know were sending on your behalf. Moving to quarantine or reject before fixing those systems can disrupt legitimate mail, including receipts, automated notices, and messages from a line-of-business application.
DMARC reports are technical, but their purpose is practical. They show who is sending mail that claims to be from your domain, whether it passes authentication, and where failures are occurring. That information helps you separate a configuration gap from active impersonation.
What Email Authentication Does Not Fix by Itself
Authentication is a foundation, not a pass to the inbox. Receiving providers also consider sending reputation, recipient engagement, message content, list quality, complaint patterns, server configuration, and whether the recipient has a rule or filtering setting that affects delivery.
A fully authenticated message can still be filtered. A message with a poor or missing authentication setup may still arrive in some inboxes. The goal is not to chase a single result from one test. The goal is to give every legitimate message a consistent, verifiable identity and remove preventable technical problems.
Authentication also does not stop every phishing message. Criminals can send from unrelated domains or use lookalike names. What DMARC can do is reduce the ability to send unauthenticated mail that pretends to use your own protected domain.
Helpful Protections Beyond SPF, DKIM, and DMARC
Once the core records are working, several related standards can improve visibility and transport security. They are useful, but they should not distract from getting SPF, DKIM, and DMARC right first.
Brand Indicators for Message Identification, or BIMI, can allow a verified brand logo to display in supported inboxes. It has stricter requirements, including a properly enforced DMARC policy, and it is not a substitute for authentication.
Mail Transfer Agent Strict Transport Security, or MTA-STS, tells other mail servers that they should use secure Transport Layer Security, or TLS, connections when delivering mail to your domain. TLS Reporting, or TLS-RPT, provides a way to receive reports when those secure delivery attempts fail. These records focus on the connection between mail servers, while SPF, DKIM, and DMARC focus on message identity.
Whether to add these controls now depends on your mail setup and your team’s capacity to maintain the records. If you use multiple domains or have legacy systems, it is usually better to complete one accurate layer at a time than to publish records you cannot monitor.
A Practical Authentication Check
Start by identifying every legitimate source of mail. Include employee email, marketing platforms, website forms, payment systems, scheduling tools, help desk software, scanners, copiers, and applications that send alerts. Ask each vendor which domain it uses in the From address and whether it supports SPF and DKIM alignment.
Then work through four checks:
- Confirm that your domain has one valid SPF record and that it covers current sending services.
- Enable DKIM within each sending platform and publish its required DNS key records.
- Add a DMARC record in monitoring mode and review the reports for unknown or failing senders.
- Test messages from each critical system, not just a single employee mailbox.
Keep a simple record of who can change DNS, who owns each sending platform, and when the records were last reviewed. This is especially useful when an outside marketing firm, web developer, or former IT provider has access to part of your email setup. Authentication failures often come from unclear ownership rather than a difficult technical problem.
If a required update involves DNS or a mail server your team does not manage, bring in the person or provider who does before making changes. A small error in an SPF, DKIM, or DMARC record can affect legitimate mail, so changes should be deliberate and tested.
Your next step is to run MailArrive’s free email health check and review the Report Card. It grades your domain’s authentication records and points to the exact issue to fix first.