My DTE has its sello de recepción from Hacienda. Does that mean the customer received it?

No. The sello de recepción confirms that the Ministerio de Hacienda validated and accepted the document. Delivery to the customer is a separate step, and in most setups it happens by email sent from your invoicing provider. A document can be fiscally valid and still be sitting in a spam folder.

Do I have to publish DKIM if my invoicing provider already signs its messages?

Yes, if the invoices go out with your domain in the From header. DMARC only accepts a signature whose signing domain lines up with the From domain, so a signature made with the provider domain does not help your alignment. Ask the provider for the DKIM records to publish on your own domain.

Can I just add a second SPF record for the invoicing provider?

No. A domain may publish only one record starting with v=spf1. A second one produces a PermError under RFC 7208, which fails SPF for every sender on the domain, including the ones that were working. Merge the provider include into the existing record instead.

DTE Invoices Going to Spam: The SPF and DKIM Fix

Say a 14-person distributor in Santa Tecla issues around two hundred electronic invoices a day. Every DTE goes up to Hacienda, the sello de recepción comes back, the billing system shows green the whole way down. Then three customers call in the same week asking where their invoice is. Nothing bounced. The mail landed in spam, or in a quarantine the customer's IT looks at once a quarter, and accounting found out by telephone.

We get called in for this several times a year in El Salvador, and it is almost never the invoicing system. It is an email authentication problem wearing an invoicing costume. Here is the order we work through it, which is also the order that keeps you from breaking something else on the way.

How a DTE actually reaches your customer

The fiscal half of the process is the part everyone knows. Your system builds the DTE in JSON, signs it electronically, transmits it to the Ministerio de Hacienda, and receives the sello de recepción that gives the document fiscal validity. Hacienda's electronic invoicing guidance then puts the delivery on the issuer: the customer has to receive the DTE file and its readable version, the PDF carrying the QR code that lets anyone verify the document against the Hacienda portal.

That last step is ordinary email. And in most implementations we open up, it is not your mail server sending it. The invoicing provider sends it, from their own infrastructure, with your company on the From line. To Gmail, to Outlook, to whatever the customer reads mail in, that is a third party sending messages that claim to be you. It is the exact shape of a phishing attempt. The only thing separating your invoices from that verdict is authentication that you have to publish in your own DNS.

Why invoice mail fails more often than the rest of your mail

Staff mail leaves through Google Workspace or Microsoft 365, which sign it correctly once the domain is set up, so it behaves. Invoice mail takes a different road, and four things go wrong on it.

Nobody ever authorised the provider. The domain has one SPF record naming Workspace and nothing else, so every message the provider sends fails SPF from the first day it was switched on.
The provider signs with its own domain. DMARC does not care that a message carries a valid signature. It cares whether the signing domain in the d= tag, or the domain SPF checked in the Return-Path, lines up with the domain in the From header. RFC 7489 calls that identifier alignment, and even the default relaxed mode requires the same organisational domain on both sides. A message signed flawlessly by your provider is unaligned mail as far as your policy is concerned.
There are two SPF records. Someone published a second TXT record starting with v=spf1 instead of merging into the first. RFC 7208 makes that a PermError, and a PermError fails every sender on the domain, including the ones that worked yesterday.
The record went over ten lookups. SPF evaluation is capped at ten DNS-querying mechanisms, plus two void lookups, in RFC 7208 section 4.6.4. Workspace, an invoicing provider, a CRM and a mailing tool reach that ceiling faster than people expect, and the failure mode is the same PermError.

The receiving side has also tightened. Google's sender guidelines ask every sender to authenticate with SPF or DKIM, to use TLS, and to keep user-reported spam below 0.3 percent, and senders above roughly 5,000 messages a day to Gmail accounts need SPF, DKIM and a published DMARC record. A month-end invoice run crosses that line without anyone in the company thinking of it as bulk mail.

First, find out how your provider actually sends

Before touching DNS we ask a customer to forward one real invoice email with full headers, and we read it. There are three architectures and they need three different fixes.

The provider sends as you. The From header is your domain. This is the common case, and the one that needs both an SPF authorisation and a DKIM key published on your domain.
The provider sends as itself. The From header is the provider's domain and your company name sits in the display name. Your DMARC policy is not involved at all. Delivery rides on the provider's reputation, and your job shrinks to making sure the reply-to address reaches a person who works for you.
The provider relays through your mailbox. It signs in to your Workspace or Microsoft 365 account over SMTP and sends from there. Authentication is already correct because your own platform signs the message. Failures here are sending limits, an expired app password, or a relay setting, never DNS.

The headers answer this in about ten seconds. Look at Return-Path, at the d= value inside the DKIM-Signature, and at what Authentication-Results reports for spf, dkim and dmarc. If you would rather not read them by hand, paste the message into our header analyzer.

Authorising the provider in SPF and DKIM

Everything in this section applies to case one. Ask your provider for two specific things and guess at neither: the exact SPF include they publish, and the DKIM records they want on your domain. Any provider worth paying documents both. If yours cannot answer, that is useful information about the provider.

SPF stays a single merged record at the root of the domain, with every sender inside it:

Type:  TXT
Host:  @
Value: v=spf1 include:_spf.google.com include:spf.proveedor.example ~all

Two rules to keep in your head while you edit it. There is only ever one record beginning with v=spf1 on a given name, and the ten-lookup ceiling counts what your includes include, not just what you typed.

DKIM is the half that actually survives forwarding, so it matters more than SPF here. In Google Workspace you generate the key in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, keeping the defaults of a 2048-bit key and the google selector, and publish what it shows you:

Type:  TXT
Host:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

A 2048-bit key does not fit in a single 255-character DNS string. Google's instruction is to split it into several quoted strings one after another in the same record, which most DNS editors handle for you. When the record resolves, go back to the console and click Start authentication, because publishing the key does not turn signing on.

Then do the same for the invoicing provider, using whatever host and value they give you. If your SPF budget is already tight, the cleaner move is to give the provider a subdomain of its own and let it carry the weight:

Host:  facturacion
Value: v=spf1 include:spf.proveedor.example -all

Invoices then leave as facturacion@tudominio.example, the root record stays small, and a problem with the invoicing sender can never take down the mail your staff sends. We reach for this whenever a client has more than three external senders. The longer version of that arithmetic is in our guide on getting under the SPF ten-lookup limit.

DMARC, and the report that tells you the truth

With SPF and DKIM in place you still cannot see what receivers are doing with your invoices. DMARC is what turns that into data. Start at p=none, which changes nothing about delivery and only asks for reports:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@tudominio.example; fo=1

Give it two weeks. The aggregate reports will show you every source sending under your domain, which is usually where a company discovers the marketing tool nobody mentioned, or an old server still relaying order confirmations. Drop one into our DMARC report analyzer if the XML is not your idea of a good afternoon, and read how to read an aggregate report for what each row means.

Only once every legitimate sender shows up aligned do you move to quarantine and then to reject. Going straight to p=reject on an invoicing domain is how a company stops delivering its own facturas on a Monday morning, and we have been called in to undo exactly that. The staged version is in our rollout guide.

When the authentication is already right and invoices still land in spam

It happens, and this is the list we work down.

The attachments. A DTE email carries a JSON file, which is unusual in ordinary business mail. If the recipient runs Workspace or Microsoft 365, an attachment rule on their side can quarantine the message with no bounce at all. This is worth asking about directly, because it looks nothing like an authentication failure in the headers.
The From address is a no-reply nobody trusts. Customers marking invoice mail as spam is a real signal against you, and an unreachable sender earns that treatment.
The monthly spike. A domain that sends forty messages a day and then eight thousand on the last day of the month looks like a compromised account from the outside.
Wrong or dead customer addresses. Bounces from stale addresses in the customer master file damage the reputation of a domain that is otherwise behaving.
Shared hosting in the path. If any part of the chain still routes through a shared hosting mail server, you inherit the reputation of everyone else on that machine.

A short checklist for whoever handles billing

One SPF record, every sender merged into it, under ten lookups.
DKIM published and switched on for your mail platform, and for the invoicing provider separately.
A DMARC record at p=none with a working rua, read after two weeks before you harden anything.
One test invoice a month to an address at a different provider than your own, opened and checked.
The list of external senders written down somewhere, and reviewed when you change provider.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, and email deliverability is the work we do most. For a company on DTE the useful first step is a diagnosis rather than a rewrite: what is published today, which senders are genuinely aligned, and in what order to change things so nothing stops on a working day. Our email troubleshooter and DMARC analyzer are free and cover most of that in a minute. If you would rather hand it over, see how we work or book a short call and bring one invoice email with its headers.

El Salvador DTE invoices landing in spam: authorising your provider in SPF, DKIM and DMARC