Zeppol / Guides

Invoice email deliverability: SPF, DKIM and DMARC for invoices that actually arrive

Last updated 3 September 2026

An invoice sitting in a spam folder is not a small annoyance. It is an unpaid invoice, a chased email, and — once e-invoicing is mandatory — a compliance record you cannot prove you delivered. This is the practical guide: why invoice mail gets filtered, what SPF, DKIM and DMARC actually do, how to set a sender domain up properly, and how to verify it in about twenty minutes.

Why invoice emails get filtered in the first place

Look at your invoice email the way a spam filter does. It arrives from a machine, carries an attachment, states an amount of money, and asks the recipient to pay it into a bank account. That is a perfect description of an invoice — and a perfect description of invoice fraud, which is one of the most common attacks mailbox providers deal with.

Because the shapes are identical, filters lean almost entirely on one question: can we prove this mail really comes from the domain it claims? If the answer is no, the rest of your effort does not matter. The usual reasons invoices go missing:

• Unauthenticated sending. Your app, ERP or plugin sends as [email protected] from its own servers, but your DNS never says those servers may.
• Broken alignment. SPF or DKIM passes for the sending service's domain, not for the domain the recipient sees in the From: line. To DMARC, that is a fail.
• A cold or shared sending domain. Brand-new domains and shared pools carry no reputation, or someone else's bad one.
• Corporate gateways. Business recipients — the only people who get B2B invoices — sit behind stricter filtering than consumer inboxes, often quarantining silently.
• Attachment handling. Some gateways unpack, rewrite or strip attachments. A hybrid ZUGFeRD PDF can arrive with its embedded XML mangled, which passes as “delivered” but fails as an invoice.
• Hard bounces treated as noise. A typo'd or retired buyer address bounces, the bounce lands in a mailbox nobody reads, and everyone assumes the invoice arrived.

The three records, explained simply

SPF, DKIM and DMARC are three DNS records that together answer “is this sender legitimate?”. They are not alternatives — you want all three, and DMARC only means anything once the first two are right.

Alignment is the part people miss

Most “but we have SPF!” cases fail on alignment. A sending service often uses its own bounce domain, so SPF passes for mailer-example.net while your recipient sees [email protected]. Different domains, so DMARC treats the SPF pass as irrelevant. The fix is to authenticate your domain at the service: add its DKIM keys to your DNS (so DKIM signs as yourshop.de) and, where offered, set a custom return-path or bounce subdomain.

Reading a DMARC record

A reasonable starting record, then a reasonable end state:

• v=DMARC1; p=none; rua=mailto:[email protected]; — enforce nothing, but collect daily reports on who is sending as you. Live here for a few weeks.
• v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]; — unauthenticated mail goes to spam. Move here once the reports show every legitimate sender passing.
• v=DMARC1; p=reject; rua=mailto:[email protected]; — unauthenticated mail is refused outright. This is what protects your customers from fake invoices in your name.

Do not jump straight to p=reject. Shops typically send from more places than they remember — the store platform, an invoicing app, a helpdesk, a newsletter tool, an accountant's system — and enforcement without inventory means your own mail disappears.

Choosing the sender domain

Invoices should come from an address that is unmistakably yours and separate from your marketing:

• Use your business domain. A German buyer's accounts-payable team should recognise the sender without thinking. Sending as a generic freemail address, or as your app vendor's domain, costs you both trust and DMARC alignment.
• Prefer a dedicated subdomain — invoices.yourshop.de or billing.yourshop.de. Reputation is tracked per (sub)domain, so a rough newsletter week cannot drag your invoices down with it.
• Make the From: name human. “Yourshop Rechnungen” beats “noreply”. A no-reply address on a legal document is also a bad look when a buyer needs to query it.
• Make replies work. Point Reply-To at a monitored mailbox, and read the bounce mailbox — a bounce is the single most useful delivery signal you get.
• Warm the subdomain gently if it is brand new: real invoices at normal volume are naturally good traffic, so the main risk is a sudden bulk backfill on day one.

One clarification specific to Shopify: authenticating your domain for Shopify's notification emails does not authenticate a third-party invoicing app. Each system that sends as your domain needs its own DKIM entry in your DNS, and each needs to be visible in your DMARC reports before you enforce.

Verify it in twenty minutes

1. Look up what you publish today. dig +short txt yourshop.de and dig +short txt _dmarc.yourshop.de. One SPF record only — two is a permanent error, so merge them if you find two.
2. Send a real invoice to a Gmail address you own, then open the message menu and choose Show original. You want SPF: PASS, DKIM: PASS and DMARC: PASS, and the domains beside SPF and DKIM should be your own.
3. Repeat to a Microsoft 365 address, because most German B2B buyers are there rather than on Gmail. Check the Authentication-Results header and whether it landed in Junk.
4. Open the attachment from the received mail, not from your own outbox — then validate it. A hybrid ZUGFeRD file that lost its embedded XML in transit still looks fine to a human.
5. Turn on DMARC reports with a rua= address and read them for two weeks. Every legitimate sender should show up passing before you tighten p=.
6. Check your bounces are visible to a person — or better, to software that flags the order so someone fixes the buyer's address.

Why this is a compliance question, not a marketing one

Under the German rules a structured e-invoice may be transmitted by email; a Peppol connection is not required if the buyer agrees to that route. But two obligations outlive the send button. The invoice has to reach the buyer to do its job, and both parties must be able to produce it later — the structured file itself, unaltered, for the statutory retention period (currently eight years for invoices under German rules; confirm your own case).

So “we emailed it” is not an answer if the mail was quarantined and nobody noticed, and “we still have the PDF” is not an answer if the machine-readable XML is what counted. Deliverability and retention are the unglamorous half of e-invoicing compliance.

How Zeppol sends e-invoices reliably

Zeppol builds the invoice from your Shopify order as an EN 16931 document, Peppol BIS Billing 3.0 UBL, validates it before it leaves, and then treats delivery as a tracked step rather than a hopeful one:

• Authenticated sending from your own domain, with DKIM records you add once to your DNS, so DMARC aligns on the address your buyer actually sees.
• Validation before sending. An invoice that would be rejected downstream never goes out — including the VAT arithmetic, reverse-charge treatment and VIES-checked buyer VAT numbers.
• Bounce handling that reaches a human. Hard bounces are surfaced against the order instead of vanishing into a no-reply mailbox.
• Peppol when the buyer is on it, with the receiving access point's signed AS4 hand-over receipt kept against the order: the strongest evidence e-invoicing offers, though it is hand-over, not the buyer's acceptance.
• The exact file, kept. What was sent is what is stored, so the audit question has a boring answer.

And the honest boundary: Zeppol is not a tax suite and not an email marketing platform. It does not file your VAT returns, advise on your obligations, or run your campaigns — and it cannot edit your DNS for you. It gets a correct e-invoice to your buyer and keeps the record straight.

Go deeper

• Germany's 2027 B2B e-invoicing mandate — dates, thresholds, and XRechnung vs ZUGFeRD.
• EU B2B e-invoicing on Shopify — which countries mandate what, and when.
• Peppol for Shopify — the delivery network, and when email is not enough.
• EN 16931 explained — the standard behind XRechnung, ZUGFeRD and UBL.

Frequently asked questions

This guide is general information for Shopify merchants, not legal or tax advice. Mandate dates, retention periods and national rules change, and edge cases exist — confirm your own obligations with a qualified tax adviser.