Email Deliverability Basics for Guides

Nothing you write decides whether your email arrives. Three DNS records and a hostname do, and Google published the list. Since February 2024 every sender to a personal Gmail account has had to meet a set of requirements, and reading them is instructive because not one of them is about your subject line, your offer or your writing. They are about authentication, about reverse lookups, about transport security and about message format. An operator sending a season announcement to two hundred past clients is subject to the same list as a company sending two million, minus one threshold. The whole thing is an afternoon of work at your domain provider, done once, and most guides have never done any of it. Everything else about running email well sits under the getting-booked hub.

What actually decides whether your email arrives?

Configuration you do once, not words you write each time.

Every guide who has ever had a message vanish assumes the copy did it, and starts rewriting subject lines.

The published requirements point somewhere else entirely, and they are worth reading in the order Google lists them.

Set up SPF or DKIM authentication for your sending domains. Ensure sending domains or addresses have valid forward and reverse DNS records. Use a secure transport connection. Keep your reported spam rate low. Format messages to the internet message standard. Do not impersonate Gmail sender headers.

Five of those six are infrastructure, and the sixth is a rule about honesty rather than craft.

Which means an operation with none of it configured is fighting a headwind that no amount of rewriting removes.

And an operation with all of it configured has removed the only variables it controls, leaving the ones it cannot.

The behaviour side, meaning what happens after your message lands and how recipients react to it, is a separate subject covered in the piece on landing in spam.

Bass Tours ATX, TX

What changed in February 2024?

The guidelines stopped being advice.

The page states that starting 1 February 2024, all email senders who send email to Gmail accounts must meet the requirements in that section.

Before that date the same material read as best practice, which is exactly how most small operators still treat it.

The wording is not ambiguous, and the consequence is stated as plainly: if you do not meet the requirements, your email might not be delivered as expected, or might be marked as spam.

A personal Gmail account, for the purposes of that page, means one ending in gmail.com or googlemail.com.

Look at your own client list and count how many of the addresses on it end that way. For most guiding operations it is the majority.

So this is not a rule about somebody else's mail. It is the rule governing most of the addresses you hold.

The requirements are published by Google in its email sender guidelines.

What happens over five thousand a day?

A second, stricter list applies.

The page splits its requirements in two, and the dividing line is five thousand messages per day to Gmail accounts.

Below it, you need SPF or DKIM, meaning either one satisfies the requirement.

Above it, you need SPF and DKIM and DMARC, though the guidance notes the enforcement policy in your DMARC record can be set to none.

Above it you also need sender alignment, and your marketing and subscribed messages must support one-click unsubscribe with a visible unsubscribe link in the body.

Almost no guiding operation crosses that line, which sounds like relief and is actually the trap, because the guidance then recommends setting up all three regardless.

Its exact recommendation is to always set up the three methods for your domains, which is a stronger statement than the minimum requirement it sits beside.

What tooling makes that easier is compared in the email tools piece.

What is SPF, in one paragraph?

A published list of who may send as you.

The protocol specification is unusually candid about the problem it exists to solve, opening with the observation that email on the internet can be forged in a number of ways.

It notes that existing protocols place no restriction on what a sending host can use as the sender address of a message or the domain it announces itself with.

So the framework lets a domain owner explicitly authorise the hosts allowed to use their domain names, and lets a receiving host check that authorisation.

In practice that is one text record at your domain, listing every service that sends on your behalf.

Google's guidance adds the failure mode plainly: if your third-party senders are not included in your record, messages from them are more likely to be marked as spam.

That is the single most common misconfiguration in small operations, because the booking system, the newsletter tool and the office mail are usually three different senders.

The specification is published by the IETF as RFC 7208, which obsoletes an earlier version.

What is DKIM, and why does key length matter?

A signature, and there is a stated minimum.

Where the first record says which servers may send, the signing method proves that the domain owner actually sent a given message.

Receiving servers use it to verify exactly that, which is a different question from whether the sending server was authorised.

The guidance carries a specific number here that most setup articles omit: sending to personal Gmail accounts requires a key of 1024 bits or longer.

It then recommends 2048 bits for security reasons where your domain provider supports it.

That matters because some older provider defaults sit below the stated minimum, and a key that is too short is a silent failure rather than a visible error.

If you send through a provider, the guidance says to verify that they authenticate your domain's mail with both this and the sender framework.

Which is a question to ask before signing up rather than after a season of poor delivery.

Why the domain itself matters is set out in the piece on using your own domain.

What is DMARC doing on top of those two?

Telling receivers what to do when the first two fail.

The policy record answers a question the other two leave open, which is what a receiving server should do with a message that fails the checks.

The guidance describes it as telling receiving servers what to do with messages that do not pass, and notes that to pass, messages must be authenticated by one method or the other or both.

It adds the piece people miss: the authenticating domain must be the same domain that appears in the message sender header.

That is the alignment requirement, and it is why mail sent through a third-party tool under your own name can fail even when everything looks configured.

The guidance also recommends setting up reporting so you can monitor mail sent from your domain, or appearing to have been sent from it.

Those reports are the only way to discover somebody impersonating your domain, which for a business taking deposits is not a theoretical concern.

Starting with an enforcement policy of none, as the bulk-sender section permits, lets you read the reports before you change anything.

How your domain and business name should line up is covered in the naming piece.

Capt. Geoff Colmes Florida Keys, FL

What is a PTR record, and why does it appear here?

It proves the sending address belongs to a real host.

Both requirement lists include valid forward and reverse DNS records for your sending domains or addresses.

The guidance spells out what that means: the public address of a sending server must have a corresponding pointer record resolving to a hostname, which is the reverse lookup.

The same hostname must also carry a record resolving back to the same public address, which is the forward lookup.

And it repeats one condition twice on the same page, which is a fair signal of how often it is got wrong: the sending address must match the address of the hostname named in the pointer record.

For a guide using a hosted mail provider, all of this is the provider's job and worth confirming rather than assuming.

Where it becomes yours is if anybody ever set up sending from a server you control, which is rarer now and still happens.

The guidance names a specific tool for checking it, the administrator toolbox lookup, which reports whether the record exists.

What about shared sending addresses?

You inherit everybody else's behaviour.

A shared address is one used by more than one sender, which describes almost every affordable newsletter tool.

The guidance is direct about the consequence: the activity of any sender using a shared address affects the reputation of all senders using it, and a negative reputation can affect your delivery rate.

Its two recommendations are to make sure the shared address is not on any internet blocklist, since messages from listed addresses are more likely to be marked as spam, and to check the reputation of that shared address if your provider offers a way to.

Neither is something you can fix directly, which is the honest position: you are choosing a neighbourhood rather than building a house.

What you can do is treat a provider's answers about this as a buying criterion rather than a technical curiosity.

A provider that cannot tell you whether its sending addresses are clean is telling you something.

The alternative, running your own sending server, brings its own maintenance and is rarely worth it at a guide's volume.

Which sends belong in email at all is weighed in the piece comparing text and email.

Do you need one-click unsubscribe?

Below the threshold, no. Build it anyway.

The requirement to support one-click unsubscribe, with a clearly visible unsubscribe link in the message body, sits in the section for senders above five thousand a day.

It works through two headers, one declaring that the address accepts a one-click post and one carrying the address itself, and the receiving client then posts to it directly.

The mechanism exists because mail software sometimes fetches addresses found in header fields, and thereby accidentally triggers unsubscriptions, which the standard describes as the actuality it was written to address.

Any competent newsletter tool implements this for you, which is one of the better arguments for using one instead of sending from your own mailbox.

Two things follow for a guide. First, check that your tool actually sets those headers rather than assuming it does.

Second, remember that a legal obligation to offer an opt-out exists separately from this, and is unaffected by how few messages you send.

The standard is RFC 8058, published by the RFC Editor, and it is short enough to read in a sitting.

What does the alignment requirement mean in practice?

The name on the envelope has to match the signature.

The bulk-sender list states it precisely: for direct email, the domain in the sender's header must be aligned with either the authenticated sending domain or the signing domain.

Put plainly, if a message says it is from your business but was authenticated as coming from a tool's domain, the alignment check fails even though both other checks passed.

That is the failure people find baffling, because every individual piece reports as configured.

The fix is at the tool: most of them offer a way to authenticate under your own domain rather than theirs, and the setup usually means adding records they supply.

Do that once for each tool that sends under your name, and be honest about how many there are.

Booking confirmations, the newsletter, the reminder run and the office mailbox are four senders in most operations, and each needs its own answer.

What those automated sends should look like is described in the automations piece.

Who sets this up, you or your provider?

Mostly them, and you have to ask.

The guidance says to set up authentication for each of your sending domains at your domain provider, using instructions the provider supplies.

For a guide that usually means three parties: whoever holds the domain, whoever runs the mailbox, and whichever tool sends the bulk mail.

Each of the three publishes its own setup instructions, and none of them will notice that the other two exist.

The practical route is to gather the records each service asks for, add them all at the domain, and then verify rather than trusting the confirmations.

It is a genuinely tedious afternoon and it is also the last time you will think about any of it, absent changing providers.

Write down what you added and why, because in two years the record you cannot identify is the one you will be tempted to delete.

Nobody will do this for you unasked, since each service considers its own part complete once its own instructions are followed.

How do you check whether it is working?

Send yourself a message and read the headers.

The simplest check is to send from each of your senders to an address you hold on a different service, then open the message's original headers and read the authentication results.

Do it once per sender rather than once, because the whole point is that your four senders are configured independently.

The guidance also mentions a specific error you may see on rejection, and points to its own troubleshooting material for delivery problems.

Beyond that, the reporting you enabled with the policy record is what tells you about mail you did not send, which no test message can show you.

None of this needs a paid monitoring tool at a guide's volume, though several exist and will happily sell you a dashboard.

Repeat the check whenever you add a service, which in practice means whenever somebody sells you something that sends email.

And repeat it once before the season, which is the only recurring maintenance any of this needs.

When those seasonal sends go out is planned in the season announcement piece.

Does message format really matter?

It is on both lists, so yes.

Both requirement sections include formatting messages according to the internet message format standard, and the guidance names that standard directly.

It adds several specifics worth knowing: the sender header should contain only one address, every message needs a valid message identifier, and single-instance headers should appear only once.

It also asks that headers not be excessively large, which is the sort of thing a badly built template does without anybody noticing.

For anyone using a mainstream tool this is handled, and the reason to know it is that hand-built sends and cheap plugins are where it breaks.

The guidance is separately explicit that headers and content should be accurate rather than misleading or deceptive.

It gives examples: subject lines starting with a reply or forward prefix when the message is neither, and sender and recipient headers listing anyone other than the actual parties.

Which is a rule about honesty stated as a technical requirement, and the two are the same thing here.

Writing the subject itself is a separate craft, handled in the subject lines piece.

Where do guides go wrong here?

Seven ways, and the first is treating it as a copy problem.

Rewriting a message that failed to arrive, when the message never reached a reader who could judge it.

Configuring the mailbox and forgetting the three other services that send under the same name.

Assuming a newsletter tool authenticates under your domain because it offered the option, without adding the records it asked for.

Leaving a signing key at a provider default below the stated minimum length.

Publishing a sender record that omits the booking system, which then sends into a headwind for a season.

Reading the five thousand threshold as permission to skip everything, when the requirement that applies to everyone sits above it.

And never sending a single test message to an address on another service, which would have shown all of it in a minute.

Collecting the addresses in the first place is covered in the piece on collecting emails.

What surprises operators here?

That the requirements say nothing about content.

Read the whole page and the only content rules are about not deceiving people, which is a floor rather than a craft standard.

The second surprise is that below the threshold you need only one of the two authentication methods, and the same page then recommends three.

The third is the key length number, which is stated as a requirement and is invisible in every provider interface.

The fourth is that alignment can fail while both underlying checks pass, which is why the problem resists casual diagnosis.

The fifth is how much of this belongs to the provider, and how little of that they will do without being asked.

Taken together, the work is an afternoon of asking three companies for their records and one evening of testing.

What arrives after that is a different set of problems, all of them about what you wrote.

The first message a new client receives is designed in the welcome sequence piece.

What do the careful operations do differently?

They keep a list of who sends as them.

The habit that separates the well-configured from the rest is a single written list of every service permitted to send under the business name.

Against each line goes what it sends, whether it is authenticated under the domain, and the date that was last verified.

That list is what makes the sender record correct, since the record is only ever as complete as your knowledge of who is sending.

They also test from each sender rather than from the mailbox, because the mailbox is the one that was always going to work.

They enable reporting and read it twice a year, which is enough to notice impersonation without becoming a hobby.

And they treat any new tool's send-under-your-domain step as part of setup rather than something to do later.

None of that is technical skill. It is bookkeeping applied to sending.

The winter run of past-client mail is planned in the winter rebooking piece.

The setup, in order

Four records, four senders, one test.

List every service that sends email under your business name, which is usually more than you expect.

Ask each one for its authentication instructions, and add every record it asks for at your domain provider.

Publish a sender record that includes all of them, since one omitted service undermines the rest.

Turn on signing at a key length of at least the stated minimum, and prefer the longer one where your provider allows it.

Add a policy record with enforcement set to none and reporting enabled, then read the first month of reports before changing it.

Confirm your provider's sending addresses carry valid forward and reverse records, which is a question to them rather than a task for you.

Send one test message from each sender to an address on a different service, and read the authentication results in the headers.

Write the list down with the date, then leave it alone until you add a service or change providers.

The reminder run that depends on all this arriving is set out in the trip reminder piece.