100% Australian owned and operated
The short version
- Email at your domain is a service from a mail provider. The domain only points at it, through
MXrecords. - A mailbox stores mail. An alias or a forward just passes it along.
- SPF, DKIM and DMARC are three DNS records that let receivers check mail from your domain is genuine. The big mail services now expect them.
- Moving your website shouldn’t touch your email, as long as the
MXandTXTrecords are left alone.
How mail finds you: the MX record
An email address has two halves. Everything after the @ is a domain name, and that’s the part the sending mail server looks up. It asks the DNS one question: which servers accept mail for this domain? The answer is your MX record. In the words of RFC 7505, “Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking at an A/AAAA record as a fallback.”
Two things follow from that picture:
- Your email is wherever your MX records point. Change them and new mail goes somewhere else straight away. Delete them and mail has nowhere proper to go.
- Your website has nothing to do with it. The site follows the
Arecord; the mail follows theMXrecord. That’s why you can move one without touching the other.
MX records carry a priority number, and lower numbers are tried first. DNS records explained covers the details.
Mailboxes, aliases and forwards
“Email at my domain” can mean three quite different things.
| What | How it works | Good for |
|---|---|---|
| Mailbox | Mail is stored at a mail provider. You sign in, and you can send as that address. | Your main business email |
| Alias | An extra address that drops into an existing mailbox at the same provider. | sales@, accounts@ |
| Forward | Mail to the address is passed on to an inbox somewhere else. Nothing is stored. | A simple contact address on a new or spare domain |
| Catch-all | Accepts mail for every address at the domain, real or not. | Catching typos, if you can live with the spam |
A forward is the lightest option, but it only receives. Replies come from your other address unless you set up sending separately. Once the address matters to your business, a mailbox is worth having. Our guides to Google Workspace, Microsoft 365 and our Axigen mailbox walk through setting one up, and Email hosting helps you choose.
Mail apps use two different protocols, which is why setup screens ask for two servers. SMTP sends mail and carries it between servers. IMAP reads the mailbox, leaving the mail on the server so every device sees the same thing.
Proving the mail is really from you
Email was designed without any check on the From address. Anyone can write hello@yourname.com.au at the top of a message. Three DNS records, added over the years, let receiving servers tell your genuine mail from a forgery.
SPF: who may send
SPF is a single TXT record that lists the servers allowed to send mail for your domain:
v=spf1 include:spf.mailhost.example -all
Read it left to right: “this is an SPF record; the servers my mail provider lists are allowed; everyone else is not.” The ending matters. -all means fail anything not listed, and ~all is a softer “treat it with suspicion”. The rules are in RFC 7208, and two of them trip people up:
- Only one SPF record. A domain “MUST NOT have multiple records”. If your mail provider and your newsletter tool each give you one, combine them into a single record with both
include:parts. - No more than ten lookups. Every
include:costs the receiver a DNS lookup, and they “MUST limit the total number of those terms to 10”. Keep the list to services you really use.
DKIM: a signature on every message
With DKIM, your mail provider signs each outgoing message, and the matching public key sits in your DNS for anyone to check. RFC 6376 puts the key in a TXT record under a name your provider chooses, called a selector: “All DKIM keys are stored in a subdomain named ‘_domainkey’.” A typical name looks like s1._domainkey.yourname.com.au.
A valid signature shows the message came from someone holding your key and wasn’t changed on the way. You switch DKIM on at your mail provider, which then gives you the record to add.
DMARC: the policy that ties it together
SPF and DKIM each check a domain, but not necessarily the one the reader sees in the From line. DMARC closes that gap. RFC 7489 says it “authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier”. In plain terms: the domain that passed SPF or DKIM has to be yours.
The record lives at _dmarc.yourname.com.au and sets a policy for mail that fails:
v=DMARC1; p=quarantine; rua=mailto:reports@yourname.com.au
| Policy | What it asks receivers to do | When to use it |
|---|---|---|
p=none | Nothing special. Just send reports. | First, while you find out who sends as you |
p=quarantine | Treat failing mail as suspicious, usually the spam folder | Once your own mail is passing |
p=reject | Refuse failing mail outright | When you’re confident nothing genuine fails |
The rua address receives summary reports from the big mail services, showing which servers are sending as your domain and whether they pass. Start at p=none, read the reports for a few weeks, fix anything genuine that fails, then tighten.
Why this matters now
These records used to be optional extras. They aren’t any more. Google’s sender guidelines, in force since February 2024, tell everyone who sends to Gmail to “set up SPF or DKIM email authentication for your sending domains”, and require senders of 5,000 or more messages a day to have SPF, DKIM and DMARC. Without them, your quotes and invoices are more likely to land in a spam folder.
There’s a second benefit. With DMARC at quarantine or reject, a scammer who forges your exact domain in the From line gets stopped at the door. That protects your customers and your name. (It doesn’t stop lookalike domains; see Keeping your domain safe.)
Why forwarded mail sometimes goes missing
SPF checks the server that hands the message over. When mail is forwarded, that server is the forwarder, and it isn’t on the original sender’s list. So a message that was fine when it left can fail SPF by the time it reaches the final inbox. DKIM usually survives the trip, because the signature travels with the message.
It’s the main reason forwarded mail occasionally lands in spam, and one more reason to give an important address a real mailbox.
Domains that don’t send email
A spare domain with no email is exactly what a forger likes: nobody is watching it. Three records shut the door.
@ TXT v=spf1 -all _dmarc TXT v=DMARC1; p=reject @ MX 0 .
The first says no server may send as this domain. The second tells receivers to reject anything that tries. The third is a “null MX”: RFC 7505 defines it as the way “to indicate that a domain does not accept email”, so senders get a clear error at once. Leave the null MX out if you forward mail from the domain.
When email goes wrong
| Symptom | Likely cause |
|---|---|
| Email stopped the day the website moved | The MX or TXT records were replaced along with the website records. Put them back. |
| Our mail goes to people’s spam | SPF, DKIM or DMARC is missing, or a new sending service isn’t in the SPF record |
| SPF shows an error | Two SPF records, or more than ten lookups |
| Some senders get a bounce, others don’t | MX records recently changed and old answers are still cached |
| Nothing arrives at all | No MX record, a typo in it, or the records were edited in a zone that isn’t live |
The MX & Email tab of the toolbox shows a domain’s MX, SPF and DMARC records as the world sees them. When a message bounces, read the bounce: it nearly always says why.
At Chill Domains. Email forwarding is included with every domain, so hello@yourname.com.au can land in the inbox you already use. For a mailbox, use a mail provider and add the MX, SPF, DKIM and DMARC records they give you in your dashboard’s DNS editor. If you just need a simple inbox while you get started, our optional Axigen mailbox sets those records up for you. If a setup guide isn’t making sense, ask us.
Terms in this lesson
- MX record
- A DNS record that names the servers accepting email for your domain.
- Mailbox
- Somewhere email is actually stored, with a login, an inbox and a sent folder.
- Email alias
- An extra address that delivers into an existing mailbox.
- Forwarding
- Sending visitors, or email, on to another destination without hosting anything yourself.
- SPF
- A single TXT record, starting
v=spf1, listing the servers allowed to send email for your domain. - DKIM
- A way for your mail provider to sign outgoing email so receivers can check it really came from your domain and wasn’t altered.
- DMARC
- A TXT record at
_dmarcthat tells receiving mail servers what to do with email that fails the SPF and DKIM checks, and where to send reports. - Alignment
- The DMARC test that the domain checked by SPF or DKIM matches the domain in the From address a reader sees.
- Spoofing
- Sending email with a forged From address so it appears to come from someone else’s domain.
- Bounce
- The automatic “this couldn’t be delivered” email you get back when a message can’t reach its destination.
- Null MX
- A special MX record that says “this domain doesn’t accept email at all”.
Every term, in full, is in the glossary.
Sources
All read on 2 October 2026.
- RFC 7505, A “Null MX” No Service Resource Record (IETF): how mail servers find the receiving server, and the null MX record.
- RFC 7208, Sender Policy Framework (SPF) (IETF): one SPF record per domain, the ten-lookup limit and the
-alland~allendings. - RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (IETF): keys are published under
_domainkey. - RFC 7489, DMARC (IETF): alignment with the From domain, and the none, quarantine and reject policies.
- Email sender guidelines (Google): what senders to Gmail must set up, in force since February 2024.