A security email alias is a public string researchers can trust: security@ on your domain, landing in a Gmail or Outlook someone actually reads. It is not a shared mailbox password, not a catch-all, and not leftover Google MX. Set the named map, cut exclusive MailerZ MX, probe from another mailbox, then publish Contact in security.txt. MailerZ history shows hops it accepted. It cannot show a report that hit the old host.
Quick answer for security email alias
Create security@ as a named alias into the on-call destination. Exclusive MX. HOLD unknowns so admin@ guesses do not train Gmail. Product path: aliases and catch-all, security, use cases. MX physics is in IETF RFC 5321 — Simple Mail Transfer Protocol. security.txt is RFC 9116.
Confirm MailerZ pricing. Free receives on one domain and three aliases. Solo is $40 per year when acknowledgments must leave as security@. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. No plan is SOC 2. No inbox SLA. This page is not a certification.
Google’s helpful-content guidance is about pages; see helpful content. A security@ that nobody opens is a brochure. A leftover MX next to that alias is a missed report.
The user problem and the decision criteria
Founders print security@ because a researcher asked, a customer questionnaire asked, or they copied a Fortune 500 footer. The useful job is a staffed path. The useless job is a string that lands in a dead Google Workspace leftover or a catch-all nobody triages.
| Question | If yes | If no |
|---|---|---|
| Will a named human open it the same day? | Create the alias. | Do not print security.txt yet. |
| Is MX exclusive MailerZ? | Reports can reach the hop. | Leftover MX steals reports. |
| Is catch-all FORWARD on? | Guesses and spam will join reports. | HOLD unknown. Named security@ only. |
| Must replies show security@? | Paid send-as. Free cannot. | Inbound-only is valid if you ack from Gmail. |
| Shared mailbox password? | Rotate. Map destinations instead. | Good. Two Gmails if two on-call people. |
Technical mail flow
The researcher’s server resolves MX, offers the envelope to the first willing host, and stops after a 250. If that host is leftover Google, MailerZ never runs the alias. History stays empty. You conclude “nobody reports.” They reported to a mailbox you cancelled.
MailerZ rewrites only the envelope with SRS. Header From stays the researcher. That matters when you file the report: you still see who wrote. Destination copies—two on-call Gmails—are one hop, two stores. They are not two MX products.
Self-send from Gmail is a bad gate for security@. Researchers are not you. Foreign probes are the gate. Unique subject. History 250. Destination search.
Names and TTLs are in IETF RFC 1035 — Domain names. After a cut, drain the old store without its MX. A report that arrived in leftover Workspace during TTL is why drain exists. It is not why you leave aspmx published.
Step-by-step setup and decision path
Name the on-call destination
One Gmail you will read the same day. A deputy if you travel. Write who covers weekends.
Create the named alias
security@ only. Optional security-reports@ if you already printed it. HOLD the rest. Do not catch-all FORWARD.
Cut exclusive MX if you have not
Delete leftover Google, Microsoft, registrar, and parking hosts. Query two resolvers.
Foreign probe
Unique subject to security@. History 250. Header From intact. Open the destination. Then a second probe to a deputy copy if you mapped two stores.
Publish security.txt after proof
Contact: mailto:security@yourdomain. Host it where RFC 9116 says. Do not invent a PGP key you do not use.
Send-as only if you will ack as security@
Solo or higher. Gmail send-as or Outlook SMTP. Two-direction probe. Free has no send-as. Ack from personal Gmail is honest if you say so.
Failure modes and proof
| What you see | Likely cause | Proof |
|---|---|---|
| Researcher says they mailed; history empty | Leftover MX or wrong zone | Second resolver lists extras |
| 250 empty inbox | Filter or HOLD typo | Recovery |
| Reports in spam with invoices | Catch-all FORWARD | HOLD unknown; named alias only |
| 550 on ack as security@ | Free plan | Paid send-as ticket |
| Former employee still reads reports | Shared password or stale destination | Remap and rotate |
| security.txt live, alias missing | You printed first | Create alias, probe, then keep the file |
Proof is exclusive MX, a history row, a staffed destination, and a security.txt that matches the alias you probed. Agencies run this per client zone. Client A can have security@ while Client B still has leftover builder MX. Do not copy a footer onto an unprobed zone.
MailerZ workflow and product boundary
MailerZ is inbound MX plus authenticated SMTP. Envelope SRS only. Header From never rewritten. It is not IMAP, not Workspace, not an open relay. Unhosted SMTP is 550 / 550 5.7.1.
HOLD stores unknown local-parts on Free. Free is one domain, three aliases, 14-day store, send-as disabled, SMTP and API disabled. Solo is $40 per year: 3 domains, 15 aliases, 90-day store, 1,000 outgoing, five outgoing per hour, unknowns forwarded. Starter is $8 or $80. Business is $19 or $190. Agency is $39 or $390. Confirm pricing. The store window helps if you remapped late. It is not a legal hold. Limits are not an inbox SLA. No SOC 2 claim lives here.
Features describe routing. They do not replace a vulnerability disclosure program, a bug bounty vendor, or a SIEM. Paid plans do not buy a badge. They buy send-as and higher caps.
Cost, alternatives, and trade-offs
| Choice | What you get | What you give up |
|---|---|---|
| Named alias into Gmail | A staffed path without a new seat | IMAP folders labeled “security” |
| Workspace seat named security | A store. Quote Google live | The Gmail the lead already reads |
| Catch-all as “security coverage” | Guesses and spam | A quiet report inbox |
| Bounty platform only | Their intake. Quote them live | mailto: for people who still use it |
| Free without send-as | Inbound reports | Acks that show security@ |
Time is a line item. A probed alias costs less than a missed critical. Leftover MX costs more than Solo. A Free-plan send-as argument still costs more than the upgrade. A bounty platform can sit beside mailto:. Dual MX cannot.
security.txt versus the alias
RFC 9116 describes a file at a well-known URL that tells researchers how to contact you. Contact can be mailto:, a URL, or other schemes. The file is not MX. Publishing Contact before the alias exists is how you advertise a black hole.
Policy, Acknowledgments, Preferred-Languages, and Expires are optional fields you should only fill if you will honor them. An Expires date in the past is worse than no file. A PGP key you lost is worse than no key. Do not invent a 90-day SLA in Policy. We do not publish an inbox SLA; do not put one in security.txt on our behalf.
Host the file on HTTPS. Researchers who cannot fetch it will still try security@ by convention. That convention only works if MX and the alias work. The web file and the MX owner are two systems. Both must be exclusive and current.
If you also run a bounty form, list both Contact methods. Do not list a Slack channel as the only path. Email remains the researcher’s lowest-friction tool when they do not want an account.
Agencies: per-client security.txt on the client domain, not on the agency domain, unless the report is about the agency. Copy-paste footers onto the wrong zone are leftover Contact.
On-call without a shared password
Two founders can both receive security@ by mapping two destinations on one alias. That is one hop, two stores. Write who acks. Do not share one Gmail password “because it is security.” Offboard remaps the destination. It does not require a new public string.
A mailing list as the destination is a product you must staff. If the list is public, reports leak. If the list is dead, reports sit. Prefer two named Gmails you can revoke.
Vacation coverage is a remap, not leftover MX to a personal domain. Temporary destination, then remap back. Probe after each remap. History will show whether the hop still accepts.
Former employees with IMAP on a leftover host will keep reading if you leave that MX up. Exclusive cut plus destination remap is the offboard. Drain the old store. Rotate passwords. Two-factor stays on.
Night pages belong in the destination Gmail, not in MailerZ as a pager. We store hops. We do not page on-call. If you need paging, wire the destination or a ticket tool. Do not invent an SLA we did not sell.
Break-glass on a HOLD body is an audit row. Use it when a typo landed a real report. That is a control. It is not SOC 2. Do not send zone passwords to support.
HOLD, guesses, and fake reports
Attackers guess admin@, root@, webmaster@, and security@. HOLD keeps unknowns out of the on-call inbox. Review HOLD on a schedule. Promote a string only if you will staff it. Catch-all FORWARD turns security@ into a spam folder with a noble name.
Fake reports and resume spam will still arrive at a public security@. Filters in Gmail are your problem after the hop. Unique probe subjects help you prove the path without waiting for a researcher. Do not train the team to ignore security@ because of noise. That is how a real report dies.
Plus-addressing is not a substitute for a printed security@. Researchers look up the convention and security.txt. IETF RFC 5233 — Sieve Email Filtering: Subaddress Extension describes subaddressing. You can use security+program@ internally. Do not make researchers guess the plus tag.
Campaign mail must not use security@ SMTP. US Federal Trade Commission — CAN-SPAM compliance guide is for lists. Mixing marketing through the security identity burns researcher trust and can look like an open relay from the outside. Unhosted send is 550. Keep it that way.
Registrar republish after a website save will steal the next report. Re-query MX the morning after anyone edits DNS. security.txt cannot fix leftover MX.
IPv6 versus IPv4 on the MX hostname is reachability after names are exclusive. Do not republish Google MX because AAAA failed. Fix the host. History shows whether we accepted the envelope.
Send-as remains a second ticket. Acknowledgments from the lead’s Gmail are acceptable if Policy says so. Acknowledgments that claim security@ on Free will 550. Upgrade when the From must match.
If a second operator needs the order without a call, send this page plus leftover MX troubleshooting. Named alias. Exclusive MX. Foreign probe. Then security.txt. That order prevents a footer with no hop.
Paid plans do not change the physics. Solo, Starter, Business, and Agency still need one inbound owner and a human who reads. The upgrade changes send-as and limits. It does not read the report for you.
The artifacts that close a security email alias are a staffed destination, two resolver listings, a foreign-probe 250, and a security.txt Contact that matches. Everything else is questionnaire comfort. Questionnaire comfort is how leftover MX survives a quarter with a noble local-part.
What researchers actually do
A careful researcher looks up security.txt, then tries security@, then maybe a contact form. They will not open a ticket in your CRM unless you listed that URL. They will not guess a plus tag. They will not wait for DNS you have not cut. If their first message bounces or vanishes, many will blog the bug instead of retrying.
They may send from a throwaway mailbox. That is why Header From must stay theirs and why leftover MX is fatal: you cannot search Gmail for a name you never received. Unique probe subjects during setup prove the path. Production reports will not use your probe subject.
Attachments and proof-of-concept files will hit Gmail’s filters. Warn the on-call person to search spam and to ask for a resend if history shows 250 and the inbox is empty. Do not ask them to disable all filters. Do not promise MailerZ will unpack malware. We forward. The destination decides.
Encryption: if you publish a PGP key in security.txt, someone must still decrypt. A key on a laptop that is offline is theater. MailerZ does not provide PGP. TLS on SMTP protects the hop in transit; it does not encrypt the body at rest in Gmail. See a later TLS article for that boundary. Do not claim end-to-end because MX used STARTTLS.
Safe-harbor language belongs in Policy if counsel wrote it. This page is not legal advice. Do not copy another company’s safe harbor. Do not put “we are SOC 2” in Policy. We are not.
Acknowledgments should be fast and boring: we got it, we will look, here is a ticket id if you have one. They do not need a marketing footer. They do not need a calendar invite. They need the path to work again next time.
Agencies and client security@
An agency can operate security@ for a client only if the destination is a person who can act. Routing reports to the agency generic inbox trains the agency to ignore them. Prefer the client security lead’s Gmail plus a deputy copy if the contract says the agency watches.
Per-zone MX. Per-zone alias. Per-zone security.txt. A template footer that still lists the agency domain is leftover Contact. Offboard remaps destinations and deletes the alias if the client leaves, or hands them the map. Do not leave MailerZ MX published beside their new host.
Quote Agency at $39 or $390 when the fleet needs more domains. Confirm pricing. The plan does not buy a disclosure program. It buys capacity for maps you still have to staff.
Night operators who add Google MX “so reports have a backup” recreate leftover MX. Backup is a second destination on one hop, or a bounty form, not a second exchanger.
Weekend cuts still need a Monday re-query. Registrar email republishes. Parking MX returns. A report that arrives Tuesday in leftover builder mail is a failed security email alias setup, not a researcher problem.
If you need another operator to run this without a call, send this page, leftover MX troubleshooting, and RFC 9116. Named alias. Exclusive MX. Probe. Then the file. That order prevents a questionnaire checkbox with no hop.
Two-factor on the destination. HOLD review weekly if you store unknowns. Export if counsel needs the old store. Drain without MX. Send-as as a second ticket. Those rules are the same as billing@ with higher blast radius.
Do not put security@ on a catch-all FORWARD “until we staff it.” That sentence is how resume spam and invoice fraud share a folder with a critical. HOLD until the named alias exists and a human is written on the ticket.
Do not use the founder’s personal Gmail as the public Contact in security.txt. Print security@, map to that Gmail. When the founder leaves, remap. The internet remembers security@, not the personal address you leaked in a footer.
SPF, DKIM, and DMARC matter when you ack as security@. They do not deliver inbound reports. Mixing authentication homework with leftover MX is how the first researcher hits Google. Cut MX. Then send-as. IETF RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a send job.
IPv6 failures after exclusive names exist are host problems. Republishing Workspace MX “so reports work while we debug” hides whether MailerZ is reachable. Fix the host. Probe again. Drain the leftover store if any cache remains.
A bounty platform and mailto: can both be listed. Dual MX cannot. If procurement asks for a named CSM, point at /contact. We will not invent one. If they ask for SOC 2, point at /security and say no.
FAQ
What is the safest way to handle security email alias?
Create security@ as a named alias into an on-call Gmail or Outlook you actually read. Exclusive MX. HOLD unknown local-parts. Probe from another mailbox before you publish security.txt. Paid send-as only if acknowledgments leave as security@. Do not share a mailbox password.
Does this require a new mailbox?
No. MailerZ is not IMAP. The destination can be the security lead’s existing Gmail. Buy hosting only if you need a separate IMAP store for reports. Two MX products still split mail.
Will it work with Gmail or Outlook?
Inbound works when exclusive MX and the alias exist. Self-send can hide leftover MX. Researchers will not self-send from your Gmail. Free has no send-as. Replies as security@ need a paid plan.
What DNS records are involved?
One exclusive MailerZ MX set, verification TXT, leftover Google or Microsoft MX deleted. SPF, DKIM, and DMARC when you send as security@. security.txt is a web file, not an MX record. See RFC 5321 and RFC 9116.
What should I test before production?
Two resolvers, a uniquely titled foreign probe to security@, history 250, Header From intact, destination search. Then publish Contact in security.txt. Do not print the address first.
Key takeaways
- Security email alias: named security@ into a staffed Gmail, not a shared password.
- Probe before you publish security.txt Contact.
- HOLD unknowns. Catch-all FORWARD is not coverage.
- Leftover MX steals reports. Exclusive owner only.
- Two destinations are copies. Two MX products are a split.
- Free receives. Solo $40/yr if acks must show security@.
- RFC 9116 is a web file. RFC 5321 is the hop. Both must work.
- Not SOC 2. Not an inbox SLA. Confirm /pricing.
Conclusion and next action
If you want security@ for vulnerability reports, staff a destination, map the alias, cut exclusive MX, probe, then print Contact. MailerZ can show hops it accepted. It cannot merge leftover Google or read the report for you. Start free on one domain and prove inbound before the questionnaire asks again.
Ready to staff security@
Start free with one domain and a named alias you will actually read.
Inbound on Free. Solo when acks must leave as security@. Sign in if the domain is already there.
Review when on-call changes, and quarterly otherwise. Author: MailerZ editorial, Secuno LLC.