Email authentication helps receiving mail systems check whether messages are authorised to use your domain. It matters when your business sends quotations, newsletters, order confirmations or password-reset emails: those messages should be recognisable as legitimate.
Three names appear repeatedly: SPF, DKIM and DMARC. They work together, but they do different jobs. This guide explains those jobs and provides a careful rollout plan for a small business using several email services.
Authentication does not guarantee inbox placement or make a message’s contents trustworthy. It is one part of dependable email delivery, alongside recipient expectations, sending reputation and sound account security.
SPF, DKIM and DMARC in plain English
| Method | Main purpose | Key limitation |
|---|---|---|
| SPF | Identifies authorised sending servers for the envelope-sender domain | A pass alone does not authenticate the visible From address |
| DKIM | Uses a domain signature to verify signed message content | The signing domain must align appropriately for DMARC |
| DMARC | Checks alignment with the visible From domain and publishes handling policy | It does not stop every form of phishing or impersonation |
For DMARC to pass, at least one of SPF or DKIM must pass and align with the visible From domain under the applicable alignment rules. Alignment is why a provider reporting “SPF passed” is not always the end of the investigation.
What Gmail currently requires
Google’s email sender guidelines require senders to personal Gmail accounts to use SPF or DKIM. Bulk senders must use SPF, DKIM and DMARC; Google also sets requirements concerning transport security, spam rates and unsubscribe handling. Its bulk-sender guidance covers approximately 5,000 or more daily messages to personal Gmail accounts, so consult the current definitions before relying on a volume threshold.
Even below that volume, Google recommends all three authentication methods. A small mailing list should still be configured correctly. These are established sender requirements, not a newly announced rule introduced for this article.
1. Inventory every service that sends for your business
Make a list before changing DNS. Include staff email, newsletter software, invoicing tools, the CRM, website forms, ecommerce receipts and support software. Ask who owns each service and which address customers see.
Use a table with service, owner, visible From domain, sending purpose, authentication status and last test date. This is the working record for the rollout. A forgotten appointment-reminder service can cause more disruption than an obvious newsletter platform.
2. Check SPF with the providers you actually use
SPF is published through DNS. Obtain the required configuration from each sending provider and review the existing record before changing it. Do not copy a Google-only example if another service also sends for the same domain.
Google’s SPF setup guide explains how to identify sending services and publish the record at your DNS provider. Keep the configuration current when adding or retiring services. A domain registrar and the organisation hosting its DNS may be different, so confirm where the active records are managed.
3. Enable DKIM for each sending service
DKIM configuration normally starts inside the sending platform, which supplies a selector and DNS record. Publish the provider’s exact values and complete its activation or verification step. Publishing a record is not necessarily the same as enabling signing.
Different services can use different selectors. Avoid replacing a working selector with another platform’s value. Google Workspace users can follow Google’s DKIM instructions; users of other platforms should use their provider’s equivalent instructions.
4. Introduce DMARC with observation first
DMARC can publish a monitoring policy, request quarantine or request rejection of failing mail. Starting with a monitoring policy can help identify legitimate senders before enforcement. Monitoring alone does not request that failing messages be blocked.
Use reports to investigate unexpected sources and alignment failures. Once legitimate sending routes are working, plan a controlled move towards enforcement. Google’s DMARC setup guide explains the configuration and rollout considerations. Do not jump to a rejection policy before testing business-critical mail.
5. Test messages, not just DNS records
For each service in the inventory, send a representative test message to an inbox you control. Review its authentication results and confirm the expected visible sender. Also verify that the message arrives and its links work.
A useful test set includes a staff message, form notification, newsletter, receipt and password-reset email where applicable. Record the service, test date, authentication outcome and any error. A green DNS check cannot demonstrate that every application is using the intended sending route.
An illustrative small-business rollout
Consider a consultancy using one platform for staff email, another for newsletters and a website plugin for appointment confirmations. The owner assigns one person to coordinate the checks instead of letting three suppliers change DNS independently.
They document the current records, confirm each supplier’s instructions and schedule a small test window. The newsletter and staff messages work, but the appointment notification uses an unexpected sender. The owner corrects that route and repeats the test before increasing DMARC enforcement.
This example is hypothetical. Its lesson is operational: define responsibility, test the less visible systems and keep a record of the change. It is not evidence that every business has the same configuration problem.
Common mistakes to avoid
- Assuming the website host is the only email sender
- Changing several records without preserving the previous values
- Testing newsletters but forgetting transactional messages
- Treating authentication as a replacement for consent and relevant content
- Leaving a former supplier authorised after it is no longer used
- Using the customer’s address as a website form’s From address instead of an appropriately authenticated business address
Once delivery is dependable, connect it to your email marketing automation workflow. Protect the sending accounts themselves using the practices in our small-business cybersecurity checklist.
Frequently asked questions
Does email authentication guarantee delivery?
No. Reputation, recipient complaints, message content and other receiving-system checks still matter.
Should I change DNS myself?
Only if you understand the active configuration and have the provider’s exact instructions. Otherwise, give your domain or email administrator the sender inventory and ask them to implement and test it.
What should I do this week?
List every sending service, identify its owner and run one controlled test from each. Resolve unexplained failures before changing enforcement policy.