Contact form messages that vanish and order confirmations landing in junk are almost always an authentication problem. Here's how to publish SPF, DKIM and DMARC properly.
A customer fills in your contact form and you never see the message. An order confirmation lands in someone's junk folder. A password reset email simply vanishes. The instinct is to blame the hosting, but the mail almost always left the server fine. It got rejected or filtered at the other end, because nothing in the message proved your domain actually authorised it.
Three DNS records fix that. They take about twenty minutes to publish and they are the difference between mail that arrives and mail that quietly disappears.
Google, Yahoo and Microsoft all now require SPF, DKIM and DMARC from any domain sending 5,000 or more messages a day to their users. Microsoft went furthest: after a rollout that started with warnings in August 2025 and moved to full enforcement that November, non-compliant mail to outlook.com, hotmail.com and live.com addresses is rejected at the SMTP level rather than dropped in junk. The sender gets a bounce, and the recipient never sees anything at all.
Most small sites send nowhere near 5,000 messages a day, so the hard requirement does not apply to them. That is worth being precise about, because plenty of articles imply otherwise. What does apply to everyone is the filtering that sits underneath the rule. Unauthenticated mail from a small domain is treated as more suspicious than it was two years ago, and a domain with no DMARC record gives receiving servers nothing to check when someone forges your address. A contact form that sends a handful of messages a day is still competing for the same inbox as everyone else, and it is being judged by the same signals.
Each one answers a different question, and receiving servers check all three.
| Record | What it proves | Where it lives in DNS |
|---|---|---|
| SPF | This server is allowed to send mail for my domain | A TXT record on the domain itself |
| DKIM | This message was signed by my domain and was not altered in transit | A TXT record at selector._domainkey.yourdomain.com |
| DMARC | Here is what to do when the first two fail, and where to send me reports | A TXT record at _dmarc.yourdomain.com |
SPF and DKIM do the proving. DMARC is the policy that ties them to the address your recipient actually sees, which is the part most setups get wrong.
SPF is a list of the servers permitted to send mail using your domain. It is a single TXT record on the domain root, and it looks like this:
v=spf1 a mx include:_spf.google.com ~allReading it left to right: v=spf1 marks it as SPF, a and mx authorise the servers already listed in your domain's A and MX records, include: pulls in a third party's list of sending servers, and the final mechanism says what to do with everything else.
If you send mail through your hosting account's own mail server, the control panel has usually created a starting SPF record for you already. Check what is there before you add anything, because of the first common mistake below. If you also send through Google Workspace, Microsoft 365, a newsletter tool or a transactional service like Postmark or SendGrid, each of those publishes an include: value in its own documentation, and every service you actually send from needs to be in the record.
Use ~all (softfail) while you are setting things up. It tells receivers that mail from anywhere else is suspicious but should still be accepted, which gives you room to discover a sending service you forgot about. Move to -all (hardfail) once your DMARC reports show every legitimate sender passing. Going straight to -all before you know what sends on your behalf is how people take down their own invoicing system.
Publishing two SPF records is the first. A domain is allowed exactly one, and a second TXT record starting with v=spf1 produces a PermError, which means SPF fails entirely rather than falling back to the first record. When you add a new sending service, merge its include: into the record you already have instead of creating another one.
Exceeding ten DNS lookups is the second, and it is easy to hit without noticing. The include, a, mx, ptr and exists mechanisms each cost a lookup, and an include can nest more lookups inside itself, so four or five third-party services can quietly blow the limit. The result is the same PermError. Plain ip4: and ip6: entries cost nothing, so replacing an unnecessary include with the provider's actual IP range is the usual fix.
DKIM signs every outgoing message with a private key held on the mail server, and publishes the matching public key in your DNS so receivers can verify the signature. Because the signature covers the message body and headers, it also proves nothing was modified along the way.
You do not write a DKIM record by hand. The sending platform generates the key pair and gives you the public half to publish, along with a selector, which is just a label that lets one domain hold several DKIM keys for different services. The record ends up at:
selector._domainkey.yourdomain.comSo a key with the selector default goes at default._domainkey.yourdomain.com, and one from a mail service using the selector s1 goes at s1._domainkey.yourdomain.com. Choose a 2048-bit key if the platform offers a choice. Every service that sends mail as your domain needs its own DKIM key published under its own selector, and unlike SPF there is no limit on how many you can have.
DMARC does two things. It tells receiving servers what to do with mail that fails SPF and DKIM, and it asks them to send you reports about what they saw. Start with monitoring only:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; pct=100Published at _dmarc.yourdomain.com, that record changes nothing about delivery. p=none means take no action on failures, and rua= is the address where daily XML reports arrive from every provider handling your mail. Those reports are the point of this step: they list every IP sending under your domain and whether it passed, which is how you find the newsletter tool or legacy script nobody remembered.
Leave it at p=none for a few weeks. Once the reports show only servers you recognise, and all of them passing, tighten to p=quarantine so failures go to spam, and later to p=reject so they are refused outright. Skipping the monitoring period is the most common way to lose legitimate mail.
A message can pass SPF and still fail DMARC. DMARC checks that the domain the recipient sees in the From: header matches the domain that SPF or DKIM authenticated. If your form sends from noreply@yourdomain.com but the mail service authenticates as its own domain, SPF passes for that service and DMARC still fails, because the two domains do not line up. Fixing it usually means configuring the sending service to sign with a DKIM key on your domain rather than its default one.
All three are ordinary TXT records, so they go in the same place. Sign in at my.lvato.com, open Services, then Manage Hosting, then Manage, and use the control panel button to reach your hosting control panel. DNS records live under the Domains section, in Manage DNS. Add each record as type TXT, with the host or name field set to the domain root for SPF, to selector._domainkey for DKIM, and to _dmarc for DMARC.
If your domain's nameservers point somewhere else, Cloudflare being the usual case, add the records at that provider instead. DNS records are read from wherever the nameservers point, not from where the site is hosted, and editing the wrong panel produces records that look correct and do nothing.
Creating the mailboxes themselves is covered separately in the email setup guide, including the IMAP and SMTP settings for connecting a mail client.
DNS changes need time to propagate, so give it an hour before testing. Then query the records directly:
dig TXT yourdomain.com +short
dig TXT default._domainkey.yourdomain.com +short
dig TXT _dmarc.yourdomain.com +shortOn Windows without dig installed, nslookup -type=TXT yourdomain.com does the same job.
For a full test, send a message from your domain to a Gmail address, open it, and choose Show original. Gmail prints the SPF, DKIM and DMARC results at the top, and all three should read PASS. If DKIM says none rather than fail, the signature is not being applied at all, which usually means DKIM is published in DNS but not enabled on the sending platform.
Publish SPF and DKIM today, add DMARC at p=none alongside them, then leave it alone and read the reports for a few weeks before tightening the policy. That order matters: every step after the first depends on knowing what actually sends mail as your domain, and the reports are the only reliable way to find out.
Every Lvato shared hosting plan includes mailboxes on your own domain and DNS management in the same panel, so all three records can be published without a separate email service. The Solo plan covers 20 email accounts, while Business and Professional are unlimited.