If you come up with a proof of a mathematical proposition, how do you verify the proof is correct?
Put it another way, how do you avoid a wrong proof?
I guess there is no definitive answer to this.
However, I believe this question is important.
Any idea, suggestion or method to help make sure a proof is correct would be appreciated.

EDIT
Thanks for all your suggestions.
I'd like to add my idea which is perhaps similar to Leslie Lamport's (I haven't read his paper yet).
My idea is basically "divide and conquer".
Divide your proof to small propositions or lemmas.
The smaller, the better.
Ideally each of these small proposition should be trivial.
To do this, first divide the main theorem into several propositions.
The main theorem should be almost trivial assuming each proposition is correct.
Then divide each proposition into several propositions.
Repeat this process until each proposition cannot be divided or trivial enough.
Then apply some or all of your ideas to each proposition.
Generalizing your theorem can help make this process easier(there is an adage(?): if your problem is difficult, generalize it).

I got this idea from the Grothendieck's approach in his EGA.
See the article "The rising sea; Grothendieck on simplicity and generality" by Colin McLarty.

(1) If possible, put it aside for a few days and see whether it still makes sense when you come back and check every step from scratch. (2) Take nothing for granted: check everything. (3) If possible, have someone else cast a beady eye on it.
–
Brian M. ScottJun 5 '12 at 7:46

Lamport suggests structuring the proof formally, with each statement accompanied by its own sub-proof in terms of simpler claims. How far should one continue this refinement? Lamport says: "My own rule of thumb is to expand the proof until the lowest level statements are obvious, and then continue for one more level. This takes discipline."

To make an awful pun on "The proof of the pudding is in the eating", "The proof of the proof is in the reading". That is, a good way to make sure it is correct is to ask experienced people to take a look at your steps. I realize you can't do this for every problem you prove, but it's an important component of developing your "mistake sense" so that you can detect problems on your own.

Informally, your proof will be valid and complete as long as each step is a valid logical step from the previous one (starting with the givens, of course), and there is no "fuzziness" about why something is happening, or how you get from one step to the next.

If there is fuzziness, that doesn't mean it's wrong, but it's a great indicator that you need to work on that point more, to make it clearer.

First and foremost you should check with a few different people, with a small variety of expertise on the topic at hand, ie someone at the same level who can check for obvious flaws, perhaps someone with more knowledge on the topic at hand who may be able to spot more deeply hidden inconsistensies, and perhaps even someone less knowledgeable than yourself who can tell you which steps are hardest to follow (I find a lot of mistakes I make come from where I make large jumps).

In general try to avoid fuzzy statements like "continue in a similar fashion" and instead try and use more rigourous principles such as induction.

Also I always find it useful to try and find a more direct and constructive proof if I can having a verifiable result makes it a lot easier to check the correctness of a proof.

Generally, I would say that a good way to find a problem with your proof, is to look away from the details for a second and consider the intuition behind the proof. Try to state the proof technique instead of the calculations, and see if the general idea behind the proof makes any sence; can you say something about $A$ by looking at the behavior of $B$, does proving $A$ mean that $B$ is false?, and so on.

Usually, when I write proofs, I start by giving the intuition of the proof, before starting the actual proof containing the details. In this way, the reader will believe my proof strategy before diving into the details.