Configure Your Domain for Email So Messages Don’t Land in Junk

Building a consultancy site is pointless if every reply to a lead lands in junk. Deliverability is mostly DNS and habit — not a prettier signature. This post is the checklist we used at ScaleMorph while standing up contact@scalemorph.com on Microsoft 365 hosted through GoDaddy.

What “email authentication” actually means

Receiving mailboxes (Gmail, Outlook, corporate filters) ask three questions about every message that claims to be from your domain:

1. SPF — Is this server allowed to send as @yourdomain.com?
2. DKIM — Is the message cryptographically signed by a key you published in DNS?
3. DMARC — What should happen if SPF/DKIM fail, and where do reports go?

There is usually no menu item called “Email authentication” in your DNS panel. You add TXT and CNAME records. Aliases (contact@, david@) do not need their own DNS — they inherit the root domain’s MX, SPF, DKIM, and DMARC.

Step 0 — Mailboxes vs aliases (save money)

For a small software house you rarely need a paid seat per brand address.

• Pay for people who need an inbox (e.g. khanhamza@).
• Add contact@ and david@ as aliases on that seat until sales volume justifies a second mailbox.
• Put contact@ on the website. Keep founder addresses off the public footer.

Aliases only change where mail is delivered. Inbox placement for outbound still depends on SPF/DKIM/DMARC for the domain.

Step 1 — Confirm MX (receiving)

Your apex MX should point at your real mail host. For Microsoft 365 it looks like:

Type: MX
Name: @
Value: yourdomain-com.mail.protection.outlook.com
Priority: 0

If mail already arrives at your primary address, MX is fine. Fix authentication next — that is what protects sends.

Step 2 — One SPF record (never two)

SPF is a single TXT on @ that starts with v=spf1.

For GoDaddy Microsoft 365 we use:

Type: TXT
Name: @
Value: v=spf1 include:secureserver.net -all

Rules that matter:

• Only one SPF TXT on @. Multiple SPF records break validation.
• If you still send through another provider (legacy SendGrid, Amazon SES), merge includes into that one line — do not add a second SPF.
• Example if you still use those ESP paths:
  v=spf1 include:secureserver.net include:sendgrid.net include:amazonses.com -all

We retired SendGrid as the site “email gun.” Outlook/Microsoft 365 is for people mail and light notifies — not bulk blasts. Bulk belongs on a proper ESP (or HubSpot campaigns) later, often from a send subdomain so the root domain stays clean.

Step 3 — Microsoft DKIM (exact values from your tenant)

Microsoft DKIM is not something you invent. In the Defender / authentication UI for your domain:

1. Open Email authentication (DKIM) (admin account).
2. Select your domain → Create DKIM keys.
3. Copy the two CNAMEs Microsoft shows.
4. Add them in GoDaddy DNS.
5. Turn Sign messages for this domain with DKIM On.

Ours looked like this pattern (your hostnames will include your org id):

Type: CNAME
Name: selector1._domainkey
Value: selector1-yourdomain-com._domainkey.NETORGxxxx.k-v1.dkim.mail.microsoft

Type: CNAME
Name: selector2._domainkey
Value: selector2-yourdomain-com._domainkey.NETORGxxxx.k-v1.dkim.mail.microsoft

Do not confuse these with older marketing DKIM names such as SendGrid’s s1._domainkey / s2._domainkey. Different selectors can coexist. Delete the SendGrid pair only when nothing still sends through SendGrid.

DNS alone is incomplete until the Microsoft toggle is On.

Step 4 — Exactly one DMARC record

DMARC is a TXT on _dmarc. One record only — duplicates make policy unreliable.

Start in monitor mode:

Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:you@yourdomain.com

• p=none — report only; do not reject yet.
• After a few weeks of clean SPF/DKIM on real mail, tighten to p=quarantine (then eventually p=reject if you are ready).

We had accidentally published two _dmarc rows; removing the duplicate was required before trusting the policy.

Step 5 — What you can ignore for day-one inboxing

These often exist on an M365 + GoDaddy domain and are fine to leave:

• autodiscover → Outlook
• Teams / Skype (sip, lyncdiscover, related SRV)
• Domain verification TXT (….onmicrosoft.com, Google site verification)
• Website A / www records (separate from mail auth)

Odd MX rows on a hostname (e.g. khanhamza.yourdomain.com → SES) do not change mail to khanhamza@yourdomain.com. Apex MX still governs @yourdomain.com.

Step 6 — Prove it with a real send

1. Send from Outlook (ideally Send as contact@ if the alias is configured).
2. Deliver to a Gmail (and ideally one other provider).
3. Open the message → Show original / view headers.
4. Confirm SPF: PASS, DKIM: PASS (Microsoft), DMARC: PASS.

If DKIM fails, wait for DNS TTL, re-check the CNAMEs, and confirm signing is enabled in Microsoft.

Habits that matter as much as DNS

• Warm a new mailbox with normal 1:1 mail before campaigns.
• No scraped cold blasts from the same domain you use for client work.
• Keep a stable From address (contact@ or a named sales address).
• When you run campaigns at volume, isolate them on a send subdomain and authenticate that subdomain separately — so sales mail on the root stays safer.

Checklist we left ourselves

• MX → Microsoft 365
• Single SPF including your real senders
• Microsoft selector1 / selector2 DKIM CNAMEs + signing On
• Single _dmarc with rua=
• Public site address = contact@ (alias OK)
• Test headers show PASS / PASS / PASS

DNS is not glamorous. It is the difference between a lead reading your reply and never seeing it. Do this before you buy traffic or automate outreach.