Good email sending account security is the difference between a bad afternoon and a bad quarter. If someone takes over the account you use to send mail, they inherit your authenticated domain, your sending reputation and your customers trust. In a few hours they can send phishing or spam that passes every technical check, and you may spend weeks recovering from the blocklistings and filtering that follow. We want to help you make that unlikely and survivable. This guide covers who should have access and at what level, how to protect sign-ins, how to handle credentials per application, how to offboard people, what compromise looks like in your data, and what to do in the first hour.
Everything here is general best practice that applies to any sending platform. Where a control depends on your plan or configuration, we say so, and the right move is to check which controls your MigoSMTP account offers before you plan around them. We do not assume specific role names or sign-in features.
Why sending accounts get targeted
Attackers like sending accounts for the same reasons you do. The infrastructure is reliable, the domain is authenticated, and the mail reaches inboxes. A stolen login or leaked key turns all of that into a tool for them. Typical goals include phishing campaigns that borrow your brand, bulk spam, invoice fraud and password-reset abuse aimed at third parties.
The damage is rarely limited to the attacker. Mailbox providers judge your domain and IP addresses by what they see, so a burst of abusive mail lowers the delivery of your legitimate messages for days or weeks. Recipients who receive fraudulent mail in your name lose trust that is hard to rebuild. If the account also exposes recipient lists, delivery logs or message content, there may be a data protection issue on top of the deliverability issue.
Think in blast radius: You cannot guarantee that no login or key will ever leak. You can decide how much damage any one leak can do. Every control in this guide either makes a leak less likely or makes its consequences smaller.
Team access and least privilege
Least privilege means each person and each program gets the minimum access needed for the job and nothing more. It is the most effective single idea in account security, because it limits what a stolen credential can do. Start by writing down who has access today and why. Most teams are surprised: former contractors, an agency from two years ago, a founder who set the account up and handed it on.
Separate the roles
Even a small team benefits from thinking in role groups. Whether your account has built-in roles, custom permissions or only a single owner login is something to check in your MigoSMTP account. The table shows the split we suggest as a target and the reasoning behind it. Map it onto whatever controls you actually have.
| Role group | Typically needs | Typically should not have | Why |
|---|---|---|---|
| Developer | Create and rotate application credentials, read delivery logs for debugging, manage webhooks for their services | Billing details, the ability to export full recipient lists, permission to change owners | Code is the most common place for secrets to leak, so limit what a leaked developer login can reach |
| Marketer | Compose and schedule campaigns, view campaign reports, manage templates and lists | Credential creation, domain and DNS changes, billing | Campaign tools send to many people at once, so protect them from tampering with infrastructure |
| Finance | Invoices, plan and payment settings, usage totals | Sending, credentials, recipient data | Payment details are valuable to fraudsters and finance rarely needs to send |
| Auditor or reviewer | Read-only view of settings, users, logs and reports | Any change permission | Independent review only works if the reviewer cannot alter what they review |
| Owner or administrator | Everything, including user management and recovery | Daily sending work done under the owner login | Keep this group very small and use it rarely |
Two practical rules help. First, keep the number of owners to the smallest figure that still survives someone being on holiday, which is usually two. Second, do not let people use an owner login for ordinary work. If a marketer needs to send a campaign, they should do it as a marketer.
Per-person access beats shared logins
A shared login is convenient on day one and expensive forever after. You cannot tell who changed a setting, everyone who ever knew the password stays a risk, and rotating it interrupts the whole team. Give each person a named user. Where your account supports it, tie sign-in to your company identity system so that disabling a person in one place removes access everywhere. If your account does not offer named users on your plan, treat that as a risk to record and compensate for with tighter credential handling and more monitoring.
| Approach | Accountability | Offboarding | Blast radius of a leak |
|---|---|---|---|
| One shared login for everyone | None, since actions cannot be traced to a person | Change the password and tell everyone | The entire account |
| Named users, no role split | Good | Remove one user | The entire account through one person |
| Named users with least privilege roles | Good | Remove one user | Only what that role can do |
Protect sign-ins with two-factor authentication
A second factor means that a stolen password alone is not enough to log in. NIST guidance on digital identity treats multi-factor authentication as a core control, and the OWASP authentication guidance recommends it for accounts that carry real risk. A sending account certainly does. If your MigoSMTP account offers two-factor authentication, turn it on for every user, starting with owners and anyone who can manage credentials.
- Prefer phishing-resistant methods. Hardware security keys and passkeys resist fake login pages better than codes typed from a text message. Authenticator apps are a solid middle option. Text-message codes are better than nothing but are the weakest choice.
- Use a password manager. Every user should have a long, unique password for the account. Reuse across sites is how most account takeovers actually happen.
- Secure the recovery path. An attacker who cannot beat your login may go after the password reset. Protect the mailbox that receives reset messages with the same strength of sign-in, and keep recovery codes somewhere safe and offline.
- Do not rely on a feature that may not exist. We do not claim any particular sign-in feature here. Check which controls your MigoSMTP account offers, and if a control is missing, compensate by protecting the identity and mailbox behind each login more strictly.
SMTP credentials and API keys: one per application
People log in to a dashboard, while programs authenticate with SMTP credentials or API keys. Both are secrets that let software send mail as you, and both tend to end up in repositories, chat messages, tickets and old server backups. Our guide on API key security, permissions, storage and rotation goes deep on the mechanics. The principles for account security are these.
- One credential per application and per environment. Production, staging and each separate service get their own. If one leaks, you revoke one and the rest keep working. Your logs also tell you which system is doing what.
- Narrowest permission available. A service that only sends does not need to manage users or read data. Where a key can be limited, limit it.
- Keep secrets out of code. Use environment variables or a secrets manager. Add scanning to your repositories and build pipelines so an accidental commit is caught before it spreads.
- Do not paste secrets into chat or email. Share through the secrets manager so access is logged and can be withdrawn.
- Rotate on a schedule and after any exposure. Create the new credential, deploy it, confirm sending works, then revoke the old one. Never revoke first on a live system without a plan.
- Name and date them. A credential named after its owner, system and creation date is easy to audit. A credential named test2 is a mystery waiting to cause an outage.
If you are still deciding how a given application should connect, our comparison of SMTP and API sending covers the trade-offs, and every connection should use TLS, as RFC 8314 explains. A credential sent over an unencrypted link is a credential given away.
Offboarding people, contractors and agencies
Most access problems are not attacks at all. They are former staff, expired contracts and forgotten integrations that still work. A written offboarding routine turns this from an awkward judgement call into a checklist, and it works for employees, freelancers and agencies alike.
- Remove or disable the named user on the day of departure. If sign-in is tied to your identity provider, disable them there first.
- List every credential the person could read or create, including application keys in the secrets manager, repositories and old tickets.
- Rotate those credentials, starting with production. Shared secrets are the reason offboarding is painful, which is another argument for per-application credentials.
- Review the last thirty days of their activity: users created, credentials issued, settings changed, exports run.
- Check webhooks, forwarding rules and API integrations they set up, and remove any you cannot account for.
- Transfer ownership of campaigns, templates and automations to a named colleague, so work does not break when the account disappears.
- Record the date, the steps taken and who confirmed them.
Do the same when an agency or vendor engagement ends. External parties often hold the most privileged access and the least attachment to your security policies.
Spot a compromised account early
Attackers rarely announce themselves. They send quickly, before anyone notices, so your best defence is knowing what normal looks like and watching for departures from it. Here is how to read them for security.
| Signal | What it can mean | First check |
|---|---|---|
| Sudden jump in sending volume, especially overnight or at weekends | A stolen credential used for bulk sending, or a runaway script | Which credential or user is sending, and from which system |
| Bounce rate spike with many unknown-user errors | Someone sending to a harvested or guessed address list | Recent recipients that your team does not recognise |
| Complaint rate rising quickly | Recipients receiving mail they did not expect | Subject lines and content that your team did not write; see complaints and feedback loops |
| Logins or API calls from new countries, networks or IP addresses | A credential in the hands of someone else | Whether the person was travelling, and whether the key is used from your servers only |
| New users, credentials, webhooks or forwarding rules you did not create | An attacker building persistence | Creation time, creator and whether it matches a planned change |
| Domain or settings changes outside a change window | Tampering with identity or routing | Change history and the user behind each change |
| Authentication reports showing unfamiliar sources using your domain | Misuse of your domain, possibly through a leaked credential or a separate spoofing attack | DMARC reports; read your DMARC aggregate reports |
Build alerts that people actually act on
- Set thresholds relative to your normal pattern, for example a multiple of the usual hourly volume, rather than a number someone guessed once.
- Send alerts to at least two people and to a shared channel, so a holiday or a missed message does not hide an incident.
- Check what alerts and logs your MigoSMTP account provides, and fill gaps with checks on your own side, such as counting messages your applications submit.
- Review a short weekly summary of volume, bounces, complaints and new credentials. Unusual quiet is also worth a look, since a broken integration is its own problem.
A worked example: spotting and containing a leaked key
Here is an invented example with illustrative numbers, to show how the signals and the response fit together. A small online shop normally submits about 400 messages a day, all from one order-confirmation service, with a bounce rate around 1 percent and almost no complaints.
| Time | What the monitoring shows | Action |
|---|---|---|
| 02:10 | Volume in the previous hour is 3,200 messages against a normal hourly figure near 20 | Automatic alert goes to the on-call engineer and the shared channel |
| 02:20 | Bounce rate in the same hour is about 18 percent, mostly unknown-user errors, and the content is a payment-update message nobody on the team wrote | Engineer treats it as a compromise, not a bug |
| 02:25 | The sending credential belongs to the staging service, not production | Revoke the staging credential at once; production keeps running |
| 02:40 | Volume returns to normal; the key is found in a code snippet pasted into a public issue tracker by a contractor | Remove the snippet, rotate the production credential as a precaution, and check the contractor access list |
| Next day | Review of the sent messages, bounce and complaint data, and blocklist status | Document the timeline, pause marketing sends until reputation is stable, and update the policy to ban secrets in tickets |
The damage in this example was roughly 3,000 unwanted messages in about twenty minutes, rather than hundreds of thousands over a weekend. That outcome came from three earlier decisions: separate credentials per environment, an alert based on normal volume, and an on-call person who knew they were allowed to revoke a key without asking permission first.
Incident response: the first hour and after
Decide the plan before you need it. During an incident people are stressed, and half the delay comes from not knowing who is allowed to do what. NIST publishes a widely used incident handling guide (SP 800-61) whose phases are preparation, detection and analysis, containment, eradication and recovery, and lessons learned. The steps below follow the same shape, adapted to a sending account.
- Contain. Revoke the suspected credential, disable the suspect user or pause the affected application. Do this first, before you are sure of the cause. Prefer the narrowest action that stops the abuse.
- Preserve evidence. Export logs, message samples and the list of users and credentials before they change. Note times in one time zone.
- Assess scope. Establish what was sent, to whom, from which credential and for how long. Check whether any recipient data, templates or settings were read or changed.
- Eradicate. Rotate every credential the attacker may have seen. Reset passwords and sessions for affected users, turn on or re-check second factors, and remove anything you did not create, such as users, webhooks and forwarding rules.
- Recover. Bring legitimate sending back in stages, starting with the most critical mail. Watch bounce and complaint rates closely. If mail was blocked, follow the steps in removing a blocklisting.
- Communicate. Tell internal stakeholders first. Check legal or contractual notification duties with your compliance contact. If recipients received fraudulent mail, say so plainly and tell them what to ignore.
- Learn. Within a week, hold a short blameless review. Fix the root cause, update this plan, and add the detection that would have caught it sooner.
Contact us early: If you think your MigoSMTP account is involved in abuse, contact our support team promptly through the contact page. Tell us what you saw, when it started and what you have already done. We cannot help with what we do not know about.
A security checklist for your sending account
- Every person has a named user, and no shared logins remain.
- The owner group has two members at most, and nobody uses it for daily work.
- Roles follow the split between developer, marketer, finance and auditor, as far as your account allows.
- Two-factor authentication is on for every user where it is available, and recovery paths are protected.
- Each application and environment has its own credential, named and dated, with the narrowest permission available.
- Secrets live in a secrets manager or environment variables, and repositories are scanned for leaks.
- Alerts exist for volume, bounces, complaints, new credentials and unusual sign-in locations, and reach at least two people.
- An offboarding routine exists and is used for staff, contractors and agencies.
- The incident response plan is written, names owners for each step and includes an emergency contact path to us.
- Access reviews and credential rotation happen on a calendar, at least quarterly.
- Your sending domain is authenticated and monitored; see how to authenticate a sending domain.
Sources and further reading
These public references informed the practices above. They are general guidance, not statements about any MigoSMTP feature.
- NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide
- NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management
- OWASP Authentication Cheat Sheet
- OWASP Secrets Management Cheat Sheet
- RFC 8314, Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Questions about securing your account? Tell us how your team sends mail and we will help you think through access, credentials and monitoring.
Frequently asked questions
Why is a sending account such an attractive target?
A working sending account gives an attacker trusted infrastructure, an authenticated domain and a ready-made audience. They can send phishing or spam that passes SPF and DKIM, which is far more convincing than mail from a throwaway server. The cost lands on you as blocklistings, rejected mail and damaged domain reputation.
Is two-factor authentication really necessary if the password is strong?
Yes. Strong passwords still leak through reused credentials, phishing pages and malware on a laptop. A second factor stops most of those attacks from becoming a login. Check which controls your MigoSMTP account offers, and where it does not offer one, protect the mailbox and identity account tied to the login as strongly as you can.
What is the difference between SMTP credentials and API keys for security?
Both are secrets that let a program send mail as you. What matters is how you scope and store them. Prefer one credential per application and environment, give it the narrowest permission available, keep it in a secrets store and rotate it on a schedule. A single shared secret used everywhere means one leak compromises everything and you cannot tell which system leaked it.
Should the whole team share one login to keep things simple?
No. A shared login hides who did what, makes offboarding painful because everyone knows the password, and prevents you from applying different permissions to different jobs. Per-person access costs a few minutes to set up and pays for itself the first time you need an audit trail.
How quickly should I remove access when someone leaves?
On the same day, and ideally before the conversation where they are told. Remove their named access, rotate any shared or application credential they could read, and review their recent activity. Do the same for contractors and agencies when an engagement ends.
What are the earliest signs that an account is compromised?
Look for sending volume far above your normal pattern, a sudden jump in bounces or complaints, mail to recipients you do not recognise, new credentials or users you did not create, logins from unfamiliar places or networks, and messages with content your team never wrote. Any one of these deserves a quick look, and two together deserve immediate action.
Should I pause all sending if I suspect a compromise?
Contain first, then investigate. Revoke the suspect credential or suspend the affected user or application, and pause only what you need to. If you cannot tell which credential is involved, a broader pause for a short time is acceptable because the reputation damage of continued abuse is usually worse than a delay in legitimate mail.
Do I need to tell anyone after an incident?
Possibly. Depending on what data was exposed and where your recipients live, you may have legal or contractual duties to notify customers, regulators or partners. Ask your legal or compliance contact early. Even when no duty applies, telling affected people plainly is usually the right thing to do.
How often should I rotate credentials and review access?
Review who has access at least quarterly and after any team change. Rotate long-lived secrets on a regular schedule that you can actually keep, and rotate immediately after any suspected exposure, departure of someone who could read them, or accidental commit to a repository.