Emails from your business domain land in spam: check these records first

If emails you send from name@yourbusiness.com land in clients' junk folders, check three DNS records first: SPF, DKIM and DMARC. Look for three faults: a record that's missing, two SPF records where there should be one, or records added at a company that doesn't control your domain's DNS. You can check these records yourself before you pay to move your email elsewhere. Passing them doesn't guarantee the inbox, but it rules out the most basic configuration faults.

This is about everyday one-to-one email from your mailbox. Newsletters and website form notifications have their own causes and fixes.

Who hosts your DNS, and who sends your mail

A small business domain can involve three companies: the registrar you bought the domain from, the DNS host where the records live, and the email provider. They can be the same company or three different ones. Records only count if they're added at the DNS host your domain's nameservers point to. Adding a perfect SPF record at your registrar does nothing if the nameservers point to your web host.

To find out, look at the nameservers in your registrar's control panel. Whichever company they belong to is where you edit records.

Then list every service that sends email as your domain:

• your mailbox provider;
• your website, if its forms or shop send from your domain;
• a newsletter tool;
• invoicing, booking or CRM tools that email customers "from" you.

A sender missing from your records fails the checks even when the records look right for your mailbox.

The three records in plain words

• SPF is a list of servers allowed to send mail for your domain. It's one TXT record on the domain itself.
• DKIM is a signature added to each message. The sending service holds the private key; you publish the matching public key in DNS so receivers can check it.
• DMARC tells receivers what to do with mail that fails both checks, and where to send reports. It's a TXT record at _dmarc.

What each provider asks for, from their own setup pages:

The ~all and -all endings are each provider's own default. Google recommends ~all, which asks receivers to mark mail from unlisted servers as spam. Microsoft recommends -all, which asks them to reject it. Use what your main mailbox provider documents and don't switch without a reason.

Copy current values from your provider's page rather than from this table or a forum post: Hostinger, Google Workspace SPF, Microsoft 365 SPF.

One SPF record with every sender in it

A domain must have only one SPF record. The SPF standard, RFC 7208, says that if a receiver finds more than one, the check returns an error, so your mail fails SPF everywhere. It's an easy mistake to make: a newsletter tool's setup guide says "add this TXT record", and you add a second v=spf1 record next to the first.

Merge instead. Say your mailbox is Google Workspace and a newsletter tool tells you to add include:spf.newsletter-example.com. The single record becomes:

v=spf1 include:_spf.google.com include:spf.newsletter-example.com ~all

Three more things to watch:

• The 10-lookup limit. Each include: costs at least one DNS lookup, and the services it points to can add more of their own. More than 10 in total and SPF fails. Microsoft suggests moving bulk senders such as newsletter tools to a subdomain (news.yourbusiness.com) with its own record.
• Typos. A trailing dot after a domain, include= instead of include:, or a space after the colon all break the record.
• The name field. Your DNS panel may add your domain automatically. Typing selector1._domainkey.yourbusiness.com in the name field can produce selector1._domainkey.yourbusiness.com.yourbusiness.com, which Microsoft lists as a common DKIM mistake. Enter only the part before your domain.

DKIM for each service that sends as you

Each sending service signs with its own key, so each needs its own DKIM records. They don't conflict: they use different names (selectors), and you can have several. Add the records first, wait for them to appear, then switch signing on in the service. In Google Workspace the key is generated in the Admin console under Gmail's email authentication settings; Google notes that if a message's headers have no DKIM line, it wasn't signed. In Microsoft 365 you turn DKIM on for your domain in the Defender portal after creating the two CNAME records.

A service that signs with its own domain instead of yours helps less than it looks. For DMARC, receivers check whether the signing domain matches the domain in your From address; a signature from the tool's own domain doesn't count for yours.

DMARC: start with p=none

A starting record at _dmarc.yourbusiness.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbusiness.com

p=none asks receivers to take no special action. At this stage DMARC is mostly about the reports. Receivers that support it send daily summaries of which servers sent mail as your domain and whether they passed, which is how you find the invoicing tool nobody added to SPF. Google and Microsoft both recommend starting at p=none; Microsoft describes moving to quarantine and then reject gradually, only after the reports look clean. A small business can stay at p=none until every legitimate sender passes.

The reports are XML files and can be numerous. Google advises against sending them to your own mailbox; use a separate address or a DMARC reporting service. Keep only one _dmarc record.

Test it

1. Check the records. Google's free Check MX tool checks your domain's MX and SPF records; it also takes a DKIM selector if you want to check that record.
2. Send a real message to a Gmail or Outlook.com address you own, then open the full headers. In Gmail it's More, then Show original (steps).
3. Find the Authentication-Results line. You want spf=pass, dkim=pass and dmarc=pass. Also check that the domain after header.d= is your domain, not your provider's.

If a record was added minutes ago, give it time. Hostinger allows up to 24 hours; Google, up to 48 hours for DKIM.

Records pass and mail still goes to junk

Then the problem is no longer your DNS. Narrow it down:

• One client or everyone? If only one company's mail system junks you, ask their IT person to check their quarantine and allow your domain. Their filter, their settings.
• Forwarding. If the client forwards mail from one mailbox to another, SPF can fail at the second step. DKIM can survive forwarding as long as the message isn't modified, one more reason to have it.
• Someone else sending as you. DMARC reports showing large volumes from servers you don't recognise mean your domain is being spoofed, or a mailbox has been compromised. Change passwords and turn on two-step login before anything else.
• Bulk mail from the same domain. If you also send newsletters from yourbusiness.com and they draw complaints, that can affect your everyday mail. A subdomain for bulk mail keeps the two apart.

If junk started right after you moved your website, check that the email records came across with the move. The hosting move guide covers checking MX records before you switch.

Where Hostinger fits

If your domain, DNS and mailbox are all with Hostinger and the domain uses Hostinger's nameservers, Hostinger sets up the email records automatically, so everything lives in one panel. If your DNS is elsewhere, its support page lists the exact MX, SPF, DKIM and DMARC values to add at your DNS host.

Moving your mailbox won't fix a duplicate SPF record created by another tool, or a newsletter service that never had DKIM. And if your team already works in Google Workspace or Microsoft 365, keep it and fix the records; the steps above are the same for any provider.