A customer who receives a fake invoice from your domain may not know it is fake until money, trust, or both are already gone. This guide to email authentication explains how to prove that messages sent using your domain are legitimate, helping protect your reputation and improving the odds that real business email reaches the inbox.
Email authentication is not a marketing add-on or a task reserved for large companies. If you send quotes, password resets, order updates, newsletters, or support replies from a custom domain, it belongs on your launch checklist alongside SSL, backups, and malware protection. The work happens in DNS, but the benefit is clear: mail providers and recipients have stronger evidence that your business is really behind the message.
What email authentication actually does
Email was designed for communication, not identity verification. Without authentication, a bad actor can try to send a message that appears to come from `you@yourdomain.com` even when it did not originate from your mail service. That practice is called spoofing.
Three standards work together to reduce that risk: SPF, DKIM, and DMARC. They are not interchangeable. SPF identifies permitted sending servers, DKIM adds a signed signature to messages, and DMARC tells receiving providers how to evaluate those results when a message claims to be from your domain.
Think of the system as a layered check. A sender needs permission, a message needs proof it was not altered, and your domain needs a published policy for handling failures. Proper configuration will not guarantee inbox placement, because content quality, engagement, complaint rates, and sending behavior still matter. It does, however, remove a major reason providers may distrust your mail.
The three records in a guide to email authentication
SPF authorizes your sending services
Sender Policy Framework, or SPF, is a DNS TXT record that lists the services authorized to send mail for your domain. When a provider receives mail claiming to use your domain in the envelope sender, it checks whether the sending server is allowed by that record.
A basic SPF record might authorize your business email provider, website host, and a newsletter platform. The exact value must come from each service because their sending infrastructure differs. Avoid guessing or copying a record meant for another provider.
The most common SPF mistake is publishing multiple SPF TXT records for the same domain. Mail providers can treat that as a permanent error. Combine all approved services into one record instead. Also be careful with overly broad permissions such as `+all`, which effectively authorizes anyone and defeats the purpose.
SPF has a practical limit: mail receivers generally allow only 10 DNS lookups while evaluating it. As businesses add CRM tools, help desks, ecommerce platforms, and marketing services, an old SPF record can become too complicated. Review it whenever you add or remove a sending platform.
DKIM signs each message
DomainKeys Identified Mail, or DKIM, attaches a cryptographic signature to outgoing mail. The public portion of the key is published in DNS, while your email provider keeps the private key and signs messages before delivery. The receiving provider checks the signature against the published key.
DKIM is valuable because it helps show the message was sent by an authorized system and was not materially changed in transit. It is also more durable than SPF in common forwarding scenarios, where SPF may fail because the forwarding server is not listed in your SPF record.
Your provider will normally give you a DKIM hostname containing a selector, such as `selector1._domainkey`. The selector lets a domain use different keys for different services and rotate keys without disrupting mail. Publish the supplied record exactly, then enable DKIM in the service dashboard if it is not enabled automatically.
Do not delete an older DKIM selector until you know no active service is using it. A domain can have several DKIM records, unlike SPF. Multiple selectors are normal.
DMARC sets the policy and reporting
Domain-based Message Authentication, Reporting, and Conformance, or DMARC, connects SPF and DKIM to the visible From address your customer sees. It asks a receiving provider whether SPF or DKIM passed and, just as importantly, whether the passing domain aligns with the domain shown in the From field.
That alignment requirement is what makes DMARC especially effective against impersonation. A message can pass SPF for a third-party service, but if that service is not aligned with your visible From domain, it may still fail DMARC.
DMARC also lets you publish a policy. You can begin with `p=none` to collect reports without asking providers to block mail. Once you confirm every legitimate sender is authenticating and aligned, you can move to `p=quarantine` and eventually `p=reject`. Quarantine asks providers to treat failed mail with suspicion, often routing it to spam. Reject asks them to refuse it.
Set up authentication without disrupting your email
Start by making an inventory of every system that sends as your domain. Include the obvious business mailbox provider and newsletter tool, but also look for contact forms, WordPress notification plugins, ecommerce receipts, appointment software, invoicing platforms, payroll systems, and support desks. A message sent through an overlooked tool is often the reason a strict DMARC policy causes trouble.
Next, choose the domain you want customers to see in the From field and make sure you can edit its DNS zone. If your domain is registered in one account and your hosting or email is managed elsewhere, that is fine. What matters is knowing where the authoritative DNS records are maintained.
Add or update SPF first. Gather the official SPF inclusion value or sending IP address from every legitimate sender, then create one combined SPF TXT record. Use a conservative ending while you are still auditing, typically `~all`, rather than claiming every unauthorized message should immediately fail. The right policy depends on whether your inventory is complete.
Then add DKIM records for each service. Some providers use a TXT record, while others use CNAME records that point to their managed DKIM configuration. Both approaches can be valid. Follow the provider’s instructions exactly, including selector names, quotation marks where your DNS panel requires them, and any required verification step.
After SPF and DKIM are working, publish DMARC in monitoring mode. A common starting point is a record at `_dmarc.yourdomain.com` with a `p=none` policy and a reporting address you actively monitor. DMARC aggregate reports can be technical, but they reveal which servers are sending mail under your name and whether SPF and DKIM are passing.
DNS changes can take time to appear across the internet. Do not judge success only by whether a record appears in your DNS panel. Send test messages to several major mailbox providers and inspect the authentication results in the message headers. Most business email platforms also show domain authentication status in their administration area.
Move from monitoring to enforcement carefully
Monitoring is not the finish line. A DMARC policy of `p=none` gives visibility, but it does not request protection from failed messages. Use the reports to identify unknown senders, fix alignment issues, and retire services you no longer use.
When reports show stable results, move gradually. You might apply quarantine to a percentage of mail first, then increase the percentage after confirming that legitimate transactional and marketing messages still arrive. The best timeline depends on how many teams, agencies, and software tools send on your behalf. A freelancer using one mailbox can often progress quickly; an agency or online store with multiple platforms should allow more time for testing.
Before moving to reject, check the practical details. Ensure your website forms use authenticated SMTP rather than a default server identity. Confirm marketing platforms use a branded, aligned sending domain. Ask staff not to send business mail from personal accounts while using your company address in the From field. These small gaps can create failures that look mysterious until you trace the sending path.
Common problems that weaken protection
Authentication problems usually come from configuration drift, not from the standards themselves. The following issues deserve regular attention:
- Multiple SPF records, missing services, or an SPF policy that exceeds the DNS lookup limit.
- DKIM records published correctly but never enabled in the sending provider’s dashboard.
- A visible From address that does not align with the domain authenticated by SPF or DKIM.
- A strict DMARC policy published before every legitimate sending source has been tested.
- DNS records changed during a domain transfer, migration, or email-provider switch without a full review.
A domain migration is an especially good time to audit authentication. If you are consolidating hosting, email, and domain management, document current DNS records before making changes. GiddyHost customers can use this moment to pair dependable business email and domain management with a clear authentication plan rather than treating deliverability as an afterthought.
Keep authentication current as your business grows
Email authentication is not a one-time DNS task. Review your records when you adopt a new marketing platform, change email providers, launch a new store, or give an agency permission to send campaigns. Remove old SPF entries and DKIM selectors only after confirming they are no longer in use.
Also separate authentication from sender reputation. SPF, DKIM, and DMARC establish identity, but they do not excuse poor email practices. Send only to people who expect your messages, make unsubscribe options clear for marketing email, maintain clean lists, and avoid sudden volume spikes from a domain with little sending history.
Your domain is part of your business identity. A few carefully managed DNS records help protect that identity every time you send a receipt, proposal, reset link, or campaign. Start in monitoring mode, learn what is sending under your name, and enforce protection when the evidence says you are ready.