Email authentication helps receiving systems evaluate whether messages are authorized to use your domain. SPF identifies permitted sending infrastructure. DKIM adds a verifiable signature. DMARC evaluates alignment with the visible From domain and publishes a handling policy. Authentication improves trust but does not guarantee inbox delivery. Google sender guidelines
- List every service sending mail for the domain: hosted mailboxes, website forms, billing tools, newsletters, and other applications. Collect each provider's current authentication instructions.
- In Control Center, open the website's Email → Connect mail DNS. For Lucid-hosted email, use the real values shown there and select Check mail DNS. Publish changes at the authoritative DNS provider: your retained provider, or DNS & SSL when Lucid delegation and editing are confirmed. Some records or editor permissions require support. A record in an inactive zone has no effect.
- Review the existing SPF TXT record. Maintain a single SPF policy at the applicable domain name, incorporating all authorized senders using the values those providers specify. Do not create a second SPF policy or copy an unrelated provider's example. Ask support to check syntax and DNS-lookup limits before saving a complex policy.
- Obtain the DKIM selector and public record from each sending service. Publish the exact TXT or CNAME record supplied. Virtualmin's mail server must also be configured to sign outgoing messages; publishing a record alone does not enable signing. Server-level DKIM setup is a support task. Virtualmin DKIM documentation
- Plan DMARC at
_dmarcwith support or your email administrator. A monitoring policy can reveal legitimate sources before you adopt quarantine or rejection. Arrange an authorized reporting destination and review reports. DMARC requires an aligned successful SPF or DKIM result, not simply any authentication pass. DMARC specification - Send tests from every listed service after DNS changes become visible. Inspect recipient authentication results and correct failed sources before strengthening the policy.
Check the result: Confirm published records at the authoritative provider and check real message headers. The dashboard's Matches result compares DNS with the server zone; it does not test signing or delivery. Test website-generated mail separately from mailbox-generated mail. Mail DNS checks allow one request every two minutes and cache results for up to five minutes.
Common problems: Duplicate SPF policies, incorrect DKIM selectors, copied private keys, and premature DMARC rejection can disrupt delivery. Only public DKIM material belongs in DNS. Forwarded mail may behave differently, so include normal forwarding routes in testing.
Related: Check mail DNS in Control Center, Forwarding, Delivery troubleshooting.


Leave a Reply