Support Email Deliverability: SPF, DKIM and DMARC When Your Desk Sends for You

Support email deliverability is whether the replies your team sends actually reach the customer’s inbox, and it turns on three DNS records: SPF, which lists who may send for your domain, DKIM, which signs the message so it can be checked, and DMARC, which tells receiving servers what to do when the first two fail. Your help desk cannot tell you any of it. It can only tell you the reply left.

That gap is the whole of the problem, and it is worth sitting with a minute before we go anywhere near a DNS record. Your agent writes a good answer, presses send, watches the conversation move over to solved, and gets on with the next one of them. Every system you own agrees the thing was handled. And the customer, over on their own side of it, is looking at an inbox with nothing in it, or at a spam folder nobody has opened since March, going and drafting a second message that starts with the words I never heard back from you.

Why does a help desk make deliverability harder than ordinary email?

Because of the one thing nobody warns you about at the point of buying, which is that a desk sends as you without ever sending from you.

When your team wrote out of Outlook or out of Gmail directly, the mail left the very same infrastructure your domain already pointed at, and the whole of the question answered its self without anybody having to think about it. Then you went and pointed support@ at a shared inbox, which was the right move for a dozen other reasons and we are hardly going to argue against it on our own site. Now your replies leave the vendor’s servers with your address sitting on the front of them. That is no trick and it is no flaw either, it is how every hosted desk going works, ours along with the rest of them, and it does mean the receiving server at the far end is being asked to believe a thing it has no reason yet to believe, which is that this machine it has never once heard of is allowed to write as your company.

The three records exist to hand it a reason. Here is what each of them actually does, and what falls over when the one is missing.

Their order matters more than the descriptions do, mind you. SPF and DKIM are the two checks. DMARC does not check anything, it says what ought to happen when a check fails, and it is also, quietly, the only one of the three that ever tells you anything back at all.

What does SPF actually check, and why does it break so often?

SPF is a list of who may send for you, published as a DNS TXT record, and RFC 7208 is careful about that much, it MUST be a TXT record and nothing else besides. The syntax is plain enough to read out loud, to be honest with you. You publish v=spf1, then a run of terms naming the servers and services allowed to send on your behalf, then all with a mark in front of it saying what ought to happen to everybody else.

Two things break it, and both of them go and break it silently.

The first of them is having two records. RFC 7208 says a domain MUST NOT have multiple records that would cause a check to select more than one, and what happens in practice is that somebody goes and adds a second v=spf1 line for a new service rather than editing the one already sitting there, on account of adding being the safer-feeling of the two moves. Now there are two of them, the check has no way of choosing between them, and the whole of your SPF is in error. Nobody gets an alert about it. You find out weeks later, if you find out at all.

Number two is the interesting one, and it is the reason a growing company’s mail goes strange without one person having touched the mail. RFC 7208 puts a hard limit of 10 on the terms that cause DNS lookups, which is to say include, a, mx, ptr and exists, along with the redirect modifier sitting behind them. Go past 10 and the implementation, in the RFC’s own words, MUST return permerror. Not a partial pass, mind you, and not a warning either. The whole of the record fails, and every service on the list goes down along with it, the ones near the front included, which is the part that catches people out when they finally do go looking.

Now go and count what an ordinary company has put in there. Your mail platform takes one, whether that is Google Workspace or Microsoft 365. Your marketing tool takes another. The invoicing system takes a third, and it makes no odds whether that is Stripe or Xero or whatever your finance people have been running since before any of you arrived. Shopify, if there is a store. The CRM. A form provider somebody signed up for years ago and nobody has thought about since. Your help desk, once you get one, and that is seven of them before anybody has done a single unusual thing. And each of those include: terms drags in whatever the vendor put in their own record, so the one include can quietly cost you two or three of your ten. The limit counts lookups performed rather than lines you typed, and most people who trip over it never once suspected they were near it.

One small mercy in the whole of it is that ip4 and ip6 and all cost you nothing whatever, so a record built out of IP addresses rather than includes stays cheap to evaluate. The RFC allows MTAs at least 20 seconds to work through the thing as well, so none of this is a speed problem, it is a counting problem and nothing else. And ptr, if you go and meet one in an old record, is titled do not use in the specification its self. Take it out.

Why is DKIM the record that matters most when a desk sends for you?

Now we get to the part of it that decides whether your support replies land at all, and it runs in two steps, so bear with it for a paragraph.

SPF checks the return path, which is the hidden address a receiving server bounces to, and on mail sent out by a hosted desk that return path usually belongs to the vendor rather than to your own self. So SPF can pass perfectly well, over on the vendor’s domain, and be of no use to you whatsoever, on account of DMARC never once asking whether SPF passed. What it asks is whether the domain that passed lines up with the domain sitting in the From: header your customer can actually see. That lining up goes by the name of alignment, and it is far and away the most misunderstood part of the whole business.

DKIM is the thing that rescues it. A DKIM signature carries a d= tag naming the domain that did the signing, and if your desk signs with d= your own domain, using a key you went and published at a selector on your DNS, then the signature aligns with the From: header, DMARC passes, and everything downstream of it goes quiet. Google requires a key of 1024 bits or longer for personal Gmail accounts and recommends 2048 where your DNS provider will support it, and both of those numbers are their own, printed on their own page.

That, and not spam scoring, is the reason a help desk asks you to add a DNS record during setup. Most teams paste it in without ever being told what the thing is for, and a fair few skip it altogether, on account of the mail appearing to work fine for the first while, which it does, right up until the morning it does not.

There is a second reason DKIM earns its keep, and it is one support teams meet day in, day out. Forwarding breaks SPF and leaves DKIM standing. When a message gets forwarded the forwarding server becomes the sender as far as SPF is concerned, so the check fails on a perfectly honest message that nobody did a thing wrong with, while the DKIM signature travels along with the message and verifies quite happily at the far end of it. And forwarding is no edge case on a desk either. Pointing an address into a help desk is usually done by forwarding it, and plenty of your customers forward their own mail on as well, so both directions of your traffic are running through the one mechanism SPF was never able to cope with.

What does DMARC do, and why is p=none not protection?

DMARC does two jobs, the one of them famous and the other one useful, and they are not the same job at all.

The famous one is the policy. You publish a TXT record at _dmarc on your domain, and RFC 7489 is strict about the shape of it, the v tag MUST read DMARC1, it MUST match precisely, and it MUST come first of all, with p following along behind it. The p tag takes one of three values, and the RFC describes each of them in its own words, which are worth reading rather than paraphrasing.

Go back and read the none row again, since it is the finding worth taking away off this page. A very great many companies published a DMARC record years ago, ticked deliverability off a list somewhere, and are sitting on p=none this morning in the belief that they are protected. They are not protected, and no two ways about it. They asked for no action, no action is being taken, and anybody at all can still go and send mail wearing their domain on the front of it.

The part that turns this from disappointing into daft is that p=none satisfies the requirement. The Google guidelines say senders above 5,000 messages a day to Gmail must set up DMARC, and then say in the very next breath that the policy can be set to none. So the compliance box gets ticked by a record that requests nothing whatever. That is not Google being careless, mind you, they left it open deliberately, seeing as jumping straight to reject on a domain nobody has measured yet will bin your own invoices by teatime. The trouble is that a temporary setting nobody is chasing you about tends to stop being temporary, and most of these records have been sitting at none since the day somebody added them.

Reporting is the useful job, and it is the one to actually go and use. Add a rua address into that record and receiving servers will post you aggregate reports of everything sent as your domain, the passing and the failing both, and inside of a fortnight you have a list of every system sending as you, which is a list almost nobody holds and a fair few people ought to. Two things fall out of it nearly every time. Some system nobody remembered is sending as you and failing at it. And something everybody assumed was authenticated turns out not to be.

The pct tag takes an integer between 0 and 100 and defaults to 100, so you can move to quarantine on a slice of your mail rather than the whole of it, which is how a sensible move off none is done.

What are the platforms actually requiring now?

This changed underneath one and all in 2024 and 2025, and both of the big platforms published what they were doing at the time, so these are checkable rather than folklore. We read both documents on 7 September 2026.

Google, from 1 February 2024: every sender to a personal Gmail account needs SPF or DKIM, valid forward and reverse DNS records, a TLS connection, spam rates in Postmaster Tools kept below 0.3%, and messages formatted to RFC 5322. Anyone sending more than 5,000 messages a day to Gmail needs SPF and DKIM and DMARC, needs the From: domain aligned with either the SPF or the DKIM domain, and needs one-click unsubscribe on marketing and subscribed mail. Unauthenticated mail can be rejected outright with a 5.7.26 error.

Microsoft did the same for Outlook.com consumer mailboxes, aimed at senders above 5,000 messages a day, and from 5 May 2025 non-compliant mail from those senders started going to Junk, with rejection behind it. The rejection carries 550 5.7.515 and a message saying the sending domain does not meet the required authentication level, which is at least an error you can search for.

A support desk on its own will not usually put you over 5,000 messages a day to the one platform, and if you want the arithmetic on volumes there is a whole page on Gmail’s sending limits that does nothing else. Your marketing sends might well put you over, though, and they leave from the very same domain, so the requirements land on your domain whichever system tripped them. Between the two of them those platforms cover the great bulk of the consumer mailboxes you are writing to, so treating the bulk-sender rules as the standard, rather than as somebody else’s problem in another department, is the cheaper habit by a distance.

Why does none of this show up in your support reports?

Because your desk measures the sending and nothing whatever beyond it, and that is the part of it that keeps the problem alive for months on end.

A reply goes out at 09:12. The desk records it, your first response time counts it, the conversation moves over to solved, and your SLA shows the promise kept. Every one of those is true as far as it goes, mind you. Whether the message got past the receiving server at the other end is simply not information the desk holds, and no help desk anywhere can hand it to you, ours along with the rest of them, on account of delivery being decided on somebody else’s machine well after your part in it is over.

So the failure turns up wearing something else entirely, and it turns up in ways that get blamed on people. Customers writing in twice over, or writing to a no-reply address somewhere because your reply never reached them and they went looking for another route in. Threads where somebody says they never heard back and your agent can show you the reply, sitting right there, sent. A rise in phone calls, if you have a number for them to ring. A drop in replies to a message type that used to get plenty of them. Not one of those looks the least bit like a DNS problem on a Monday morning, and every one of them looks like a support quality problem, so the whole of it usually gets sent over in that direction.

What separates the two of them is the pattern of the misses. If it is a support problem the misses land at random across your customers. If it is a deliverability problem the whole of it clusters by receiving domain, so you go and look at the three customers whose mail all sits with the one provider and find they are missing the very same things. That comparison costs about 10 minutes of somebody’s afternoon and it is the first thing to do, well before anybody starts reviewing agents.

How do you check all this before it costs you a customer?

None of the checking needs a tool bought for the purpose of it. What it needs is somebody sitting down for an hour with access to your DNS and a bit of patience.

1. Look up your own SPF record and count the terms that cause a lookup, which is include, a, mx, ptr and exists, plus redirect. Follow each include into the vendor’s own record and count what it drags in behind it. If the total is anywhere near 10 you have a problem coming, and if you have two v=spf1 records you have one already.
2. Send a message from your desk to a mailbox on a platform you do not run, then open the raw headers on it and read the authentication results line. It will tell you plainly whether SPF passed, whether DKIM passed, and whether DMARC aligned. That one line answers more than any dashboard will.
3. Check the d= value on the DKIM signature in those headers. If it names your vendor rather than your domain, your DKIM is not aligning, and that is the record to go and fix first.
4. Look up the TXT record at _dmarc on your domain. If there is nothing there you have no policy and no reports. If it says p=none, you have reports and no policy, and you should know which of the two you are looking at.
5. Add a rua address if there is not one, and leave it running for a fortnight before changing any policy. The reports will name systems sending as you that nobody has thought about in years.
6. Repeat the header test for every system that writes to customers, not only the desk. The invoicing system and the marketing tool sit on the same domain, and a failure on either of them costs your domain reputation exactly what a failure on support@ would.

Keep whatever you find, and tag the retest with your desk’s automation rules if that is easier than a spreadsheet, so next year’s check starts from a list rather than from somebody’s memory. Then go and put it in the diary. This is a set of records that rots away quietly, seeing as vendors change their sending infrastructure without telling anybody a great deal about it, and a record that was correct in March can be wrong by September with nothing at all on your side having moved.

Where our own product sits in this, and the question to ask us

We host, so the sending infrastructure underneath a Maxdesk workspace is ours to run and to keep patched, which is one of the genuine differences between a hosted desk and self-hosting, where mail deliverability becomes a job somebody on your side owns forever. That much we will say plainly.

Here is what we will not do on a page like this, which is tell you we handle the part that depends on your domain. No public page of ours documents custom sending-domain DKIM signing, so we are not going to claim it here and we are not going to deny it either. What we will do instead is give you the question, and it is the same question you should be putting to every vendor that sends mail wearing your name.

Ask them, in writing, whether their outbound mail is DKIM-signed with d= your own domain rather than theirs, and whether you are given a selector record to publish in your DNS. Then ask what the return-path domain is on their sending, so you know whether SPF can align at all. Two questions, and the answers decide whether your DMARC will pass on mail they send for you. Any vendor who cannot answer both quickly has told you something useful anyway.

There is one product fact sitting nearby that people do read as connected, and it is not. Mail leaving a free workspace carries a small line of Maxdesk branding on it, and the $20 plan takes that off and puts your own on instead. One of those is a presentation setting and the other lives in your DNS, and although they travel out in the very same message they have nothing whatever to do with one another. Confusing the pair of them has sent more than one team hunting a deliverability problem when what they had was a logo they did not care for. Our plans, for completeness, run $0 and $20 and $99, with the history window at 3 months, 12 months and 24, and every agent you have included on all three of them. The longer version of what that queue does sits on the email management software page. Checked on 7 September 2026.

The case against everything above

Fair is fair, so here are the limits, and one of them is fairly large.

Authentication is not the only reason mail ends up in a spam folder, and a page like this one could easily leave you thinking it is. What you have written matters as well. So does the reputation built up by everything else your domain has sent this year. A shared sending IP with a bad neighbour sitting on it will hurt you through no fault of your own, and a support reply stuffed with links to a domain nobody recognises is going to struggle however tidy your DNS looks. What authentication buys is the removal of one whole category of failure, and it happens to be the category you can settle once and then stop thinking about. Nobody can sell you a guaranteed inbox, and anybody offering one is selling something else.

Moving to p=reject is also not the small step it reads as up there. Turn it on over a domain with a forgotten system on it and you will bin your own mail, including things like invoices and password resets that people will notice by lunchtime. The fortnight of reports first is not caution for its own sake, it is the whole method. If your organisation is large enough that nobody can name every system sending as the domain, assume there are more of them than you think, and take the pct tag as the on-ramp it was written to be.

And we cannot check any of this for you. We cannot read your DNS, we cannot see the headers on mail you sent through somebody else’s system, and no help desk can tell you whether a message it sent was delivered rather than accepted. That is a real limit of the category and not a gap in our product, and anybody claiming otherwise is describing something narrower than they are letting on. Email is also the one channel we ship, no chat and no phone, so everything on this page is about written mail and stops there.

Last of the lot, the sources. RFC 7208 and RFC 7489 are the specifications and they do not shift about much, so those figures ought to hold for a good long while. The Google and Microsoft requirements are another matter altogether and both of them changed inside the last two years. All four were read on 7 September 2026 and they go on the list for a re-check in the early part of 2027. And if you are about to change a live DMARC policy on the strength of a paragraph on somebody’s blog, ours included, go and open the specification first.

Common questions about SPF, DKIM and DMARC for support email

Why are my support emails going to spam?
The commonest fixable cause is that your desk sends as your domain from the vendor’s servers, and nothing in your DNS authorises that. Send one reply to an outside mailbox, open the raw headers, and read the authentication results line. It will name which of SPF, DKIM and DMARC failed, which is where to start.

Do I need all three of SPF, DKIM and DMARC?
Google requires SPF or DKIM from every sender to personal Gmail accounts, and requires SPF and DKIM and DMARC above 5,000 messages a day. Microsoft asks for all three from high-volume senders to Outlook.com. Practically, DKIM is the one that matters most for a help desk, because it survives forwarding and it aligns with your From: header.

What is the SPF 10 lookup limit?
RFC 7208 says implementations must limit terms that cause DNS lookups to 10, counting include, a, mx, ptr, exists and redirect. Cross it and the record returns permerror, which fails the whole record rather than the last entry. Each include also drags in the vendor’s own lookups, so the count runs ahead of what you typed.

Is p=none enough for DMARC?
It satisfies the platform requirements and it protects nothing. The RFC describes p=none as the domain owner requesting no specific action be taken. Use it for a fortnight to collect reports, then move to quarantine on a percentage of mail once you know every system sending as you.

Why does my help desk ask me to add a DNS record?
So it can sign your outbound mail with your own domain rather than its own. That signature is what makes DMARC align on mail sent for you. It is the single most useful record in the setup and the one most often skipped, because mail appears to work without it for a while.

Does forwarding break email authentication?
It breaks SPF, since the forwarding server becomes the sender and is not on your list. DKIM signatures survive forwarding intact. That is one reason DKIM matters more on a support desk than anywhere else, because forwarding an address into the desk is the normal way of setting one up.