Email authentication is the set of DNS-based checks that helps a receiving mailbox decide whether a message claiming to be from your domain was actually sent by an approved system. The three names you will see most often are SPF, DKIM, and DMARC. They are complementary: each answers a different question, and none is a complete deliverability strategy by itself.
Why a small business should care
Your domain may send from an inbox, a newsletter tool, a CRM, a support desk, a billing platform, and a website. If those services are not configured consistently, legitimate mail can lose trust and attackers have more room to impersonate your brand. A free Beacon domain check is a practical starting point because it shows the public authentication records associated with your domain.
SPF: who may send
SPF is a TXT record in DNS that names infrastructure allowed to send mail for a domain. A simplified record might look like this:
v=spf1 include:_spf.google.com -allThe include points to Google’s published sending rules; -all signals that other sources should fail. This is only an illustration—never paste it into DNS unless it matches your provider and every legitimate sender. You must have one SPF record, so adding a marketing tool usually means carefully updating the existing record rather than creating a second one. Learn the safe checking process in how to check an SPF record.
DKIM: can this message be verified?
DKIM lets a sending provider add a digital signature. The receiver looks up a public key in DNS using a selector and checks that the signed portions of the message have not changed. You normally enable DKIM in your mail provider’s admin area and publish the exact DNS record it gives you. DKIM does not mean every message from the domain is trustworthy; it means the signed identity and message can be checked.
A frequent surprise is that an organization has a DKIM record but one of its tools is not using it. Send a test from each important platform and check the message headers. Our DKIM record guide explains where to look.
DMARC: does the visible From address align?
DMARC builds on SPF and DKIM. It evaluates whether a passing SPF or DKIM identity aligns with the domain customers see in the From field, then publishes a policy for failing mail. A basic monitoring record resembles:
v=DMARC1; p=none; rua=mailto:dmarc@example.comStart in monitoring mode when you are mapping senders. Later, after legitimate services are aligned, you can consider quarantine or reject. The policy should be a business decision supported by evidence, not a reaction to one spam complaint. See how to check a DMARC record for the details.
How the three fit together
Imagine a CRM sending an invoice as invoices@yourcompany.com. SPF may show that the CRM’s server is authorized. DKIM may verify the CRM’s signature. DMARC then checks whether the passing identity matches yourcompany.com, the domain shown to the customer. If neither aligned SPF nor aligned DKIM passes, DMARC gives the recipient a policy instruction.
A safe implementation order
- Inventory every provider that sends as your domain.
- Verify the current SPF record and consolidate authorized sources into one record.
- Enable and test DKIM in each provider.
- Publish DMARC at
p=noneand review what it reveals. - Resolve unidentified sources or alignment failures.
- Move deliberately toward stronger DMARC enforcement when your evidence supports it.
What authentication does not do
It does not guarantee the inbox. A correctly authenticated campaign can still go to spam because recipients did not opt in, bounces are high, volume changes abruptly, or the message is unhelpful. It also does not stop lookalike domains or a compromised employee account. Use it as the identity foundation, then improve list and sending practices.
Where the records live
All three controls rely on public DNS, but the changes are usually split across two places. Your sending provider supplies the record value or setup wizard; your DNS provider publishes it. The people with access to those accounts may be different. Before making a change, copy the existing record into a change log, identify the provider documentation that supports the new value, and decide how you will test. That small discipline makes it much easier to reverse a mistake.
DNS updates can take time to appear everywhere. Do not keep adding slightly different records while waiting. Confirm the published record, wait for normal propagation, then send a fresh test from the provider you configured. A message header tells you whether that provider is actually using the expected authentication.
Keep it accurate over time
DNS records are not “set once forever.” A new tool, an agency change, or a retired provider can leave stale or missing authorization behind. Keep an owner list for your sending systems and periodically run a domain check. Beacon’s monitoring is relevant after the setup is sound: it helps you notice monitored domain-health changes instead of discovering them from a customer’s missing email.
Frequently asked questions
Do I need all three?
For a business domain that sends email, SPF, DKIM, and DMARC together are the normal foundation. The correct records depend on your actual providers.
Can I copy another company’s records?
No. Authentication records must reflect your own sending services and domains. Copying records can authorize the wrong systems or break legitimate mail.