Email Security Guide — MyAdminDesk

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Three records, one domain you send from

SPF names the servers allowed to send mail for a domain. DKIM signs a message with a key you publish in DNS. DMARC tells receivers what to do when those checks fail, and where to send reports. They are DNS records for a domain you administer. They are not a way to impersonate a domain you do not own.

Start with the domain that appears in the From address your users actually send. A marketing tool, a help desk, and a mailbox host are often three senders. Each one must be in SPF or must sign with a DKIM key aligned to that From domain. The vendor pages on this desk are the place to copy the record from that vendor's console. Copy it from the console. Do not invent an include.

DMARC has a policy. p=none collects reports and does not ask receivers to reject. p=quarantine and p=reject are later, after you have read a report and recognised your own mail in it. A reject policy on day one is how you lose mail you forgot a sender for.

The SPF and DMARC generators on this site draft records. Read them. One SPF record per domain. A second TXT that also starts with v=spf1 is a broken SPF, not a backup. The network desk's DNS guide is the companion for how a record is published. This page is what the record means.

example.com in the lab, then the real domain

In the lab, write the records on a documentation name or on a domain you can break. Send one message to a mailbox you can read. Look at the headers you are allowed to see: SPF pass or fail, DKIM pass or fail, and the From domain. If you cannot see those results, you are not ready to change policy.

SPF ends in a qualifier you chose. A hard fail is a decision. A soft fail is a decision. The generator's draft is not the decision until you say so. Keep the list of senders short enough to read aloud.

DKIM is a selector and a public key in DNS. The private key stays at the sender. You do not publish the private key. You do not put it in the ticket.

DMARC rua points at a mailbox someone will open. A report that nobody reads is a policy you have not earned. Stay on p=none until a week of reports, or whatever interval you wrote down, shows only senders you recognise.

A change you can finish

The production change is the real domain, the real senders copied from their consoles, and p=none. Moving to quarantine or reject is a later ticket with the report as evidence.

Rollback is the previous TXT records, which you saved before the publish.

List every system that sends as this domain.
Publish one SPF record that includes those systems and no one else.
Turn on DKIM at the sender and publish the public key it shows you.
Publish DMARC at p=none with a rua mailbox you will read.
Send one message and read the authentication results.
Save the previous DNS records.
Do not set p=reject in this window.

Mistakes that outlive the command

email authentication fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Two SPF records on one domain.
An include you typed from memory instead of from the vendor console.
p=reject before you have read a report.
A DKIM private key in DNS or in the ticket.
A rua address nobody opens.
Authenticating a domain you do not send from, and forgetting the one you do.
Calling SPF a block of inbound spam by itself.
Publishing example.com records on the real domain.

Decisions to write down before the window

One decision for email authentication: The From domain is the one in the ticket, and every sender is listed. There is exactly one SPF record. Includes were copied from the vendor console you administer. DKIM is on for that domain, and the private key is not in the ticket. DMARC is p=none until a report has been read. The rua mailbox has an owner. A test message showed the results you expected. The previous DNS is saved. Quarantine or reject is a later window. And the vendor guide for each sender is the source of the record, not a blog.

The hour you stop

Write the hostname or the system name, the owner, and the clock time before you change anything for email authentication. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.

A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.

Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.

Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next system waits until someone else can repeat the proof from the notes. email authentication is done for this window when the proof is written, not when the tool printed a file.

This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.

Email authentication checks before policy gets stricter

Confirm this before you call the change done: One SPF record exists. Every current sender is represented. A test message was sent from the real path. The authentication results were read. DKIM passed for that message, or the failure is the open item. DMARC policy is none. The rua mailbox is real and owned. No private key is in DNS or the ticket. The previous TXT records are saved. example.com is not the production domain. A second person read the sender list aloud. No second policy change shared this window. The hostname in the prompt matches the hostname in the ticket for email authentication. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for email authentication happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Network: DNS: The Complete Guide for Admins.