Own email that doesn't go to spam: SPF, DKIM, DMARC and mailboxes explained for real

Published on 2026-08-25 by frfrand

Guía honesta sobre SPF, DKIM y DMARC: qué hace cada uno, por qué sin los tres tu correo termina en spam, y cómo montar un dominio de correo con buzones y verificación DNS conversando con una IA. Cubre crear_dominio_correo, verificar_dns_dominio_correo, crear_cuenta_correo, editar_cuota_cuenta_correo y ver_stats_dominio_correo.

Setting up your own mail server is easy. Getting that mail to land in the inbox and not in spam is the hard part, and that's where almost everyone fails.

The reason is that email was designed without any notion of authentication: originally, anyone could claim to be anyone. Everything that exists today — SPF, DKIM, DMARC — are patches built on top to cover that hole. Understanding them is not optional: if you're missing one, Gmail and Outlook will distrust your messages.

This guide explains what each one does, in what order to set them up, and how to manage domains and mailboxes with ArduMaker's MCP.

As in the rest of the cloud area, the tools work with ids: company_id for what belongs to the company, domain_id for the mail domain, and account_id for the mailbox. They are listed first and you operate on the id, never on the name.

Tools covered: crear_dominio_correo, listar_dominios_correo, ver_dominio_correo, verificar_dns_dominio_correo, eliminar_dominio_correo, ver_stats_dominio_correo, crear_cuenta_correo, listar_cuentas_correo, ver_cuenta_correo, editar_cuota_cuenta_correo, listar_cuentas_bot_correo, crear_carpeta_correo and listar_carpetas_correo.

The four records that decide if your email arrives

MX — who receives. It tells the world which server to deliver messages addressed to your domain. Without MX you receive nothing. It has numeric priority and the lowest number wins; if you have an old MX with lower priority, your email keeps going to the previous server even if you added the new one.

SPF — who can send on your behalf. It is a TXT record that lists the servers authorized to send email with your domain as sender. If a message arrives from an IP that is not on the list, the receiver knows something smells fishy.

The classic SPF trap: there can only be one SPF record per domain. If you have two, many receivers treat them as an error and cancel the protection. When you add a new sending service — a CRM, a newsletter platform — you do not add another SPF: you modify the existing one to include it. The other trap is the ten DNS lookup limit: chaining too many include: breaks the record silently.

DKIM — the cryptographic signature. Your server signs each outgoing message with a private key, and publishes the public key in DNS. The receiver verifies the signature and confirms two things: that the message came from who it says, and that no one modified it along the way. Unlike SPF, DKIM survives forwarding, and that is why it weighs more.

DMARC — what to do when something fails. SPF and DKIM detect problems but do not say what to do with them. DMARC is that policy: reject, quarantine, or just monitor. It also requests reports, which is the part almost no one takes advantage of and the most useful: you find out who is trying to send email spoofing your domain.

The practical advice: start DMARC in monitoring mode (p=none). You check the reports for a few weeks, confirm that your legitimate sends pass, and only then tighten the policy. Setting p=reject on day one is the fastest way to discover that that old application that sends invoices no longer reaches anyone.

Setting up the email domain, step by step

crear_dominio_correo registers the domain on the mail server. This is the starting point, and what it returns is as important as what it does: the DNS records you need to publish —MX, SPF, DKIM and DMARC—, including the DKIM public key generated for your domain.

And there is a rule that orders everything that comes after: the domain does not accept email nor allow mailboxes to be created until DNS verification is positive. It is not a recommendation, it is a block. crear_cuenta_correo fails while the domain is not verified.

verificar_dns_dominio_correo checks live again the MX, SPF, DKIM and DMARC, and updates the verification status. It is the tool you will use most while configuring, and the right answer to the question "is everything okay?". Instead of opening three different online validators, you ask once.

Order tip: publish first the MX and SPF, verify, then DKIM, verify again, and leave DMARC for last. If you publish everything together and something fails, you don't know which of the four it is.

listar_dominios_correo shows active domains with their verification status and plan. Typical use: quick review to detect the domain that was left half-configured months ago and no one noticed because "the email more or less works".

ver_dominio_correo brings the full details, including the verification status and the DNS records it expects. Typical use: pass to a client exactly what they need to load into their registrar, without transcribing anything by hand.

ver_stats_dominio_correo queries actual usage against the mail server: number of mailboxes, quota consumption. Typical use: anticipate a mailbox that is about to fill up, which is the silent cause of bounced emails.

eliminar_dominio_correo deserves a separate paragraph, because it is the most destructive tool in this entire guide.

It does not "unsubscribe the domain": it cascades. It deletes the domain and with it all active mailboxes —the account on the mail server and the local record—, and in practice it cannot be recovered. It is not a soft delete like the DNS domains from the previous guide; here there is no going back.

That is why it requires explicit confirmado. Without that parameter it fails with a 409 that tells you how many mailboxes would be affected — and that figure is exactly the data you need to read before confirming. If the number is not what you expected, do not confirm: first check what is inside with listar_cuentas_correo.

Mailboxes, quotas and folders

crear_cuenta_correo creates a mailbox on a domain already verified (if not, it fails) and that has not reached its mailbox limit. Typical use: hiring an employee, or the functional addresses every project needs — hola@, soporte@, facturacion@.

About the password, precisely, because here is where it's easy to go wrong. The password you set when creating the mailbox is stored encrypted, and it's not an oversight: it's what allows the messaging tools —listar_mensajes_correo, ver_mensaje_correo, enviar_correo— to work later, as they need to authenticate against the mailbox to read and send.

What is true is that it is never returned: ver_cuenta_correo gives you all the account details except that. And here's an important correction about what is sometimes assumed: there is also no MCP tool to change it. There is no way to view it or rotate it from the agent. If it needs to be changed, it's via the panel or webmail. Write it down in your password manager at the moment you create it, because from the MCP you won't see it again nor be able to replace it.

listar_cuentas_correo lists the active mailboxes of the domain. Typical use: the audit everyone postpones, where the three accounts of people who no longer work there appear.

editar_cuota_cuenta_correo changes the mailbox plan and with it its storage space. With an explicit limit: it is only upwards. Moving an account to a smaller plan is rejected; if it is really necessary to downgrade it, you must delete the account and create it again. Typical use: the administration mailbox that accumulates heavy attachments and is at 95%. A full mailbox stops receiving, and senders receive a bounce: it is a problem worth solving before, not after.

listar_cuentas_bot_correo is read-only and shows the automated accounts of the domain, only as context. The administration of those accounts —creating them, regenerating their token, deleting them— is deliberately outside the MCP: they are used by other automatic processes, and an agent touching them could break something silently on the other side. Typical use: understanding which addresses send system notifications before touching filtering rules.

crear_carpeta_correo and listar_carpetas_correo work on the IMAP structure of the mailbox; new folders hang from INBOX unless you indicate another parent. Beware of an asymmetry: there is no tool to rename or delete a folder. They are created here, they are corrected via webmail. Typical use: preparing folders by client or by year before mounting filters that archive automatically, which is the topic of the next guide in this series.

A security warning that in email matters more than anywhere else

It's worth saying it here and not in the security guide, because it's in the email where it materializes: a mailbox is the only surface of your infrastructure where a stranger can put text in front of your agent without having an account on ArduMaker. It's enough to know one of your addresses.

The MCP server treats that content as it should: what listar_mensajes_correo and ver_mensaje_correo return arrives wrapped and marked as untrusted, with the instruction to treat it as data and never as instructions — even if the message claims to come from ArduMaker, an administrator, or you.

But the other half of the defense is up to you, when authorizing the agent. The server itself publishes three scope combinations to avoid:

• Read email + execute commands on a VPS. A well-written email becomes a remote execution attempt that costs nothing to the sender. Neither half is dangerous on its own.
• Read email + send email from the same domain. An incoming message can convince the agent to reply to a third party from your domain: phishing to your own customers, signed with your DKIM.
• Read email + query databases. Foreign text plus arbitrary SQL is an exfiltration path.

The practical rule: separate agents. One that handles email, without access to servers or databases. Another that operates servers, without mailboxes. And for triage and summaries, authorizing the session in read-only is enough.

TÚ: Los mails que mandamos desde el dominio nuevo caen en spam en Gmail.

IA: listar_dominios_correo(company_id = 3) -> estudio.com -> domain_id 8, dns_verified: false

verificar_dns_dominio_correo(company_id = 3, domain_id = 8) -> MX OK SPF ADVERTENCIA: se detectaron 2 registros SPF DKIM NO ENCONTRADO DMARC NO ENCONTRADO

"Ahí están las dos causas.

Primero, hay dos registros SPF publicados. Un dominio solo puede tener uno: cuando hay dos, muchos receptores lo consideran inválido y descartan la protección entera. Hay que fusionarlos en un único registro que incluya ambos servicios.

Segundo, no hay DKIM publicado. Sin firma, Gmail no puede verificar que los mensajes salieron de tu servidor, y eso pesa mucho en su decisión.

El DMARC tampoco está, pero ese lo dejaría para el final: primero que SPF y DKIM funcionen bien.

Y una consecuencia práctica: mientras la verificación no dé positiva, el dominio no me deja crear buzones nuevos."

TÚ: Dale, dame los registros que tengo que poner.

IA: ver_dominio_correo(company_id = 3, domain_id = 8) -> devuelve los registros esperados, incluido el DKIM público generado para el dominio

"Publicá estos dos y avisame para volver a verificar: [SPF unificado] y [TXT del DKIM].

Cuando ambos den OK durante unos días, sumamos el DMARC en modo observación y miramos los informes antes de endurecerlo."

Frequently Asked Questions

Why do my emails end up in spam? The most common causes, in order: missing DKIM, more than one SPF record, no DMARC, or the domain is very new and still lacks reputation. Check these four records before looking for more exotic explanations.

Can I have two SPF records? No. The standard allows only one per domain; with two, the result is usually an evaluation failure. If you add a sending provider, merge it into the existing SPF.

What is DKIM and why does it matter more than SPF? It is a cryptographic signature of the message. It matters more because it survives forwarding: SPF breaks when a message is forwarded, DKIM does not.

Is it advisable to set DMARC to p=reject from the start? No. Start by observing, review the reports, confirm that all your legitimate sources pass, and then tighten up. Doing it the other way breaks things silently.

Does a new domain start with good reputation? No, it starts with none. Even if you have all four records perfect, high volume from day one raises suspicion. Increase volume gradually.

Can't I create mailboxes yet? If the domain hasn't passed DNS verification, no. It's a block, not a warning: run verificar_dns_dominio_correo until it returns positive.

Can the IA see mailbox passwords? No. ver_cuenta_correo returns all account details except the password. It is stored encrypted so that messaging tools can authenticate, but no tool displays it.

And can it change them? No either. There is no MCP tool to rotate a mailbox password. Save it when you create the account; if lost, change it via the panel or webmail.

Can I downgrade a mailbox to a smaller plan? No: editar_cuota_cuenta_correo only works upward. Downgrading requires deleting the account and recreating it.

What exactly happens if I delete a mail domain? All its mailboxes are also deleted and cannot be recovered. That’s why it asks for explicit confirmation and tells you beforehand how many mailboxes would be affected. Read that number before confirming.

My agent reads email. Is there any risk? Yes, and it’s worth keeping in mind: email is the way an outsider can put text in front of your agent. The content arrives marked as untrusted, but the best defense is broad: don’t give the same agent both email-read access and the ability to run commands, send email, or query databases. For triage, read-only access is sufficient.

How do I connect the MCP? By adding https://mcp.ardumaker.com/mcp in a compatible client and authorizing it with your account.

Part of the series of guides on the MCP tools of ArduMaker.